Business layer or not in MVC?_问答_开发者_运维开发者技术经验分享

When is it handy to have a business layer in your mvc web application?开发者_如何学JAVA Why do calls from the controller go straight to the dataaccess layer?

when is it handy to have a business layer in your mvc web application?

This could come handy if you have some existing or complex business logic you would like to reuse. Obviously this doesn't mean that you should always have a business layer in each application. It would depend on the specific requirements of the application and answering this question without more details about your scenario would be subjective.

So if you want an objective answer please provide an objective scenario, otherwise we are just chattering here without being constructive.

why do calls from the controller straight to the dataaccess layer?

No idea, it would be bad practice IMHO as it would make your controllers tightly coupled to your database and as a consequence difficult to unit test. What if tomorrow you decide to switch to the could? Would you like to modify your controllers? I would recommend you to make the different layers of your application as weakly coupled as possible by always working with abstractions (abstract classes/interfaces).

Keep in mind that the MVC framework is just a presentation layer. If you see wikipedia, you will realize that the Model is basically the domain layer and all business logic should be handled there.

There are several theories on whether the controller should make a direct reference to database or not. There is also a trend emerging that the Repository pattern is evil.

To make controllers lean and testable you can consider implementing a service layer to which the controller invokes.

It is always helpful to have a business layer in your application. For some very simple applications that don't do much other than CRUD, an EF or LINQtoSQL-generated object can function as a business object. The only time embedding data access calls in your controller could be acceptable is when the application is extraordinarily simple.

When you have logic that is concerned neither with the flow of control for a specific Web transaction nor data access for specific domain objects. See this section of the MSDN white paper on ASP.NET MVC unit testing:

http://msdn.microsoft.com/en-us/magazine/dd942838.aspx#id0420058

I suggest using a repository pattern to separate the details of your data access from your controllers. You don't necessarily need an entire business layer - unless you have a complex domain with many custom rules. However, you should probably keep your repository interfaces and class in a separate library so that your unit tests on the repositories don't use the web layer (you can test your controllers there).

Here is a good example of using the Unit of Work and Repository patterns with Entity Framework:

http://blogs.microsoft.co.il/blogs/gilf/archive/2010/06/21/revisiting-the-repository-and-unit-of-work-patterns-with-entity-framework.aspx

When I write my .NET code, as an Application Developer - this isn't said to inflate my own ego, but to say that my main goal is to write applications that will inevitably want to be expanded and changed over and over again.

Therefore, I write my model code under to sub folders, BOL and DAL.

The DALs handle all the database code - with a BaseDAL that has functions for getting datasets and functions for getting RETURN VALUES (with and without datasets) - I only use Stored Procedures.

And the BOLs, model the actual objects, and I call the relevant DAL whenever I want data from the database. The BOL is therefore the actual BOL, and I can change the DAL whenever I need to.

Separation is the key to good development, and separating BOLs from DALs in my opinion just makes good sense. You shouldn't make db calls from a controller, it's just plain wrong, IMHO.

The M in MVC with respect to ASP.NET/MVC is explicitly referring to the view models

Really? So what does the V stand for in ASP.NET/MVC?

The models are the business layer in mvc

EDIT (and a bit of a rant): My experience with MS products stopped with MVC v1. Back then, your model was generated by L2S or EF or whatever. I know MVVM is very popular for mvc, but that pattern says that the thing backing the view is the view model, and the thing with the business logic is the model. Rails, merb, django, symphony, backbone.js and every other mvc framework I know of calls the thing you put the business logic in the model, and when you go to wikipedia and look up mvc, you will see that it has this to say about models

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

Dont mean to be a jerk, but if ASP.net MVC is calling view models models, they are using the term incorrectly and have totally lost touch with the pattern they named their framework after.