I've had a chance to try it out and I like it very much. I'm thinking of using it in all of my future projects. I'd like to hear some critique and opinions about it. I've done a little research on the subject and I'm not sure I've seen this approach around, but I'm pretty sure that it must have been tried by some more experienced people and I'd like to avoid any pitfalls that come with it

The idea is that model is split into: 1. db access layer (dal) 2. business logic layer (bll)

  1. so db access layer contains (ideally) no logic at all other then db access logic - prepared queries that are supplied with parameters, when called, and which return results from db, if needed (in case of SELECT queries). these classes are not tested (if no logic is inserted into them), since they don't contain any if/for/while/throw... commands

  2. business logic layer which contains actual logic of the app. controllers do not see dal and only call bll which in turn calls dal when needed. bll needs to be tested (i use unit testing) and since it is kept separate from the db access, when read-only functionality is being tested, db access can be mocked using dependency injection (create mock class alternative for every dal class with all the same methods, load them via the factory method when requested from bll and depending on whether the call came from testing environment or not load either mock or 'real' class. of course in case of write functionality (DELETE, INSERT), testing would have to include db calls, so in that case 'real' class would be called, rather then mock, but this can still be very useful if system has more read then write db calls

Benefits of this approach:

  1. code separation - it keeps your business logic clean of db access code which improves readability, especially in big methods that need to make several calls to db. it makes it easier to maintain code and also allows you to encapsulate db access logic, which can be called from a numer of blls which also makes it easier to maintain
  2. it makes it easier to switch databases at any point, which is not something that happens often, but if it does happen, it's not an easy thing to do, everybody who had to do it at some point know what i'm talking about
  3. when testing bll with mock classes, it makes tests run faster since no calls to db are made. this is not too significant, but can help when you are tweaking some functionality intensively and testing it along the way. at the same time it makes it much easier to test performance of 'pure logic' detached from db calls


  1. more cluttering because of adding whole new layer of classes to the system
  2. slightly lower performance due to the added dependancy injection which takes time to resolve
  3. while mock classes do nice work, they do have to be created and maintained so there is added bureaucracy to the whole system

Am I missing anything? Do you prefer system that I described or good ol' fashion 3 layer mvc and why? I'm no guru, I'm still exploring various architectures, but I like this one very much and would love to hear what my more experienced colleagues have to say about it


2 Answers 2


MVC means model-view-controller separation for the client-side, in this case, your site. It has nothing to do with the backend layering.

Concerning backend layering; I personally like the onion approach as described here and applied here. The business layer is independent on the data layer implementation or any other technical aspect, as it only knows interfaces.

So in your controller you use the backend services (note that I'm not saying WCF services - it can be WCF, but doesn't have to be). You get data back in a specific format (the model) and you then could transform this data into viewmodels which are designed specifically for a view.

The backend services would then have the various layers that you need to implement the chosen architecture (business layer, data layer etc), but this is independent of your ASP.NET MVC site.

And don't avoid using dependency injection for the wrong reasons. It should be the default programming style.


Your instincts are good, but I don't think they should be part of MVC thinking anymore, because both business logic and data access should be independent of view. You should be able to reuse both regardless of whether they are displayed using browser, desktop, tablet, or mobile device.

I think it falls under the category of proper layering for a service oriented architecture.

Services need not SOAP; deployment choices are separate. These are interface-based objects.

What you call "business logic" is what I think of as the service layer. I disagree with the statement about business logic not knowing about persistence tier. Business logic must know about the persistence tier, because it needs to manage transactions as units of work.

I also disagree with the "lower performance due to added dependency injection". This should be done on startup and won't have a measurable effect on long-term averages. It's amortized over all the calls to the service.

Both service and persistence layers should be interface based.

  • Your business layer should not known about data layer implementation, only its interface. Business layer does not have any references and is completely independent. But maybe that's what you meant to say.
    – L-Four
    Commented Jun 3, 2013 at 12:24
  • The wording of the original suggested that it meant no package dependency whatsoever. I agree - the service package should have a dependence on the persistence package, using only the interface. The persistence package should have no dependence on the service package. No circular dependencies.
    – duffymo
    Commented Jun 3, 2013 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.