4

When is it handy to have a business layer in your mvc web application? Why do calls from the controller go straight to the dataaccess layer?

user603007
  • 11,416
  • 39
  • 104
  • 168
  • Possible duplicate of [Where does the "business logic layer" fit in to an MVC application?](https://stackoverflow.com/questions/4565681/where-does-the-business-logic-layer-fit-in-to-an-mvc-application) – icc97 May 03 '19 at 08:30
  • Also see [How to structure an enterprise MVC app, and where does Business Logic go?](https://stackoverflow.com/questions/2568010/how-to-structure-an-enterprise-mvc-app-and-where-does-business-logic-go) – icc97 May 03 '19 at 08:34

8 Answers8

4

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).

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Nice answer and I totally agree, but I have a question. Are you thinking at business layer as a simple library, maybe shared between multiple applications, or a separate service (web api?), perhaps local or remote? – jeanie77 Aug 25 '23 at 10:12
  • Could be a security issue having a business object accessing data from the Web server? – jeanie77 Aug 25 '23 at 10:18
2

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.

WorldIsRound
  • 1,544
  • 10
  • 15
1

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.

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
0

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.

Matt Briggs
  • 41,224
  • 16
  • 95
  • 126
  • 3
    Erm....I don't think that's very true. They're really page-specific models and have a much stronger coupling with the UI than the backend. – Kirk Woll Mar 25 '11 at 23:23
  • 1
    No, you are talking about view models. In an MVC context, the model is the business logic layer. – Matt Briggs Mar 25 '11 at 23:26
  • 2
    @Matt, not sure what you are referring to. The **M** in MVC with respect to ASP.NET/MVC is explicitly referring to the view models. – Kirk Woll Mar 25 '11 at 23:28
  • +1 - in *traditional* MVC they are the business layer - the domain model. There's nothing stopping you from doing that with ASP.NET MVC, though it's a bit hard to discuss since ASP.NET.MVC refers to View Models as simply "Models." – Jeff Sternal Mar 25 '11 at 23:28
  • @Kirk Woll, excellent comment. Exactly: `The M in MVC with respect to ASP.NET/MVC is explicitly referring to the view models` +1 – Darin Dimitrov Mar 25 '11 at 23:34
  • responded in an edit. if I were you guys, I would push back to MS and get them to change the naming to something more appropriate. MVC is a very old and well known design pattern, and naming things incorrectly is just going to confuse more experienced people coming to the platform. – Matt Briggs Mar 26 '11 at 00:31
0

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

Jollymorphic
  • 3,510
  • 16
  • 16
0

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

Winger
  • 676
  • 3
  • 7
  • 1
    A disadvantage of the repository pattern is that it is more difficult to set query specific settings for performance (eager loading, future queries, etc) since you've abstracted away the data/ORM layer. The ORM can be the repository itself. – Ryan Mar 26 '11 at 00:12
0

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.

mrdnk
  • 656
  • 9
  • 24
  • Though actually I guess I'm currently not using the MVC pattern as we haven't moved to .NET 4.0 yet, but I guess I'll be using a similar approach when we do. Hmmmm... well maybe, someone please enlighten me. – mrdnk Mar 25 '11 at 23:44
0

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?
mrdnk
  • 656
  • 9
  • 24