[jammycakes]

Well in the example I've just given they reduced query times from six minutes to three seconds. If that isn't increased efficiency, then I don't know what is.

The fact is that sometimes you have to ignore the "rules," because the "rules" were designed to serve a purpose that does not apply in your particular case, or perhaps never even applied at all in the first place.

The problem with trying to separate your business layer from your data access layer is that it's often difficult if not impossible to identify which concerns go into which layer. Take paging and sorting for example. If you treat that as a business concern, you end up with your database returning more data than necessary, and your business layer ends up doing work that could have been handled far more efficiently by the database itself. On the other hand, if you treat it as a data access concern, you end up being unable to test it without hitting the database.

You need to realise that software development always involves trade-offs. Blindly sticking to the "rules" is cargo cult, and it never achieves the end results that it is supposed to.

[TickleSteve]

(I was agreeing with you, not down-voting you).

[jammycakes]

My apologies :)

Incidentally I wrote a whole series of blog posts a while ago where I cast a critical eye over the whole n-tier/3-layer architecture and explained why it isn't all that it's made out to be.

https://jamesmckay.net/category/n-tier-deconstructed/