views:

280

answers:

4

I'm used to creating the UI, BLL, DAL by hand (some times I've used LINQ-to-SQL or SubSonic for the DAL). I've done several small projects using MVC since its release.

On these projects I've still continued to write a BLL and DAL by hand and then incorporate those into the MVC's models/controllers. I'm looking to optimize my time on projects this seems like overkill and a potential waste of time.

Question

Would it be acceptable to roll a DAL such as SubSonic and directly use it in the Models/Controllers of my MVC web app? Now the models & controllers would act as the BLL. I just see this as a major timesaver to not have to worry about another tier.

UPDATE:

I just wanted to add that my concern isn't really with the DAL (I frequently use SubSonic and NH) but rather focus on the BLL. Sorry for the confusion.

+10  A: 

MVC has no or little connection to the n-tier architecture. It belongs to the UI layer and serves to process interaction with the user. How you structure the rest of your application is... let's use the word orthogonal to you using MVC or not.

Business logic layer stays if you had it.

Data access layer stays if you had it.

Controllers should not be used to implement business logic. It's basically a routing layer to decide what action to invoke, what route to redirect to. A general recommendation is to keep it thin and have it take a decision on the basis of the route data and a few business logic calls.

Also models do not equal business objects. Models are a pack of data to be displayed by a view, likely to contain some auxiliary data not related to a business entity.

You can use an ORM and replace the data access layer with it. Depends on the ORM how you can integrate it. With EF you can use the entities directly as business objects.

Developer Art
+1  A: 

No, MVC does not replace a manually created UI, BLL, DAL.

  • You should not have had a manually created DAL for about - hm - 8 years or so. Lots of good or bad DAL generators are out since many many years. I had one complete ORM out around 2001. NHibernate is out for many many years now, too. THe world - even for .NET - does not end at MS offerings (which - all of them in this area, LINQ2SQL and EF) are still really low quality compared to the stuff others have out.

  • You still have to code business logic and UI in MVC - just in a different fashion than with classic ASP.NET. THe idea is not getting rid of them, it is about having them in a different orgianzation which is better for clean HTML as well as, for example, unit testing (which is really hard to do in classical ASP.NET).

TomTom
+1 The DAL isn't my concern at all. I normally use SubSonic or NH. The Hand written ones were done for a reason.
used2could
Then basically it is a different approach to program a front end layer ;)
TomTom
+4  A: 

There is not one perfect solution for how an application should be structured. You have to take into consideration the context and be pragmatic about it. For small applications architecture is far less important than for serious enterprise level applications. If you think your approach will save you a lot of time and will meet your needs now and in the future: go for it.

Seventh Element
Nice down to earth view on the subject. This is the real matter of any project that doesn't have unlimited funding and resources.
used2could
A: 

Think about it this way:

The controller handles the business logic of determining how to send the model (your DAL) to the View (UI).

Your DAL can be converted into the Model using the Repository pattern. Your Business Layer should become the Controllers and the behavior split up among various parts of the application; and your UI layer is now the 'View'.

That's MVC.

George Stocker
So you're in favor of merging the BLL into the controller and DAL into the model?
used2could
The "DAL" is your model, especially if you use the Repository pattern. The Business Logic for your application should be split out into the controller.
George Stocker
There's no converting of anything. You still have a DAL, you still have business logic (hopefully in a coherent domain model) and you still have your view concerns. Business logic should NOT be in the controllers; they are purely for routing/translating HTTP requests to the proper part of the model. MVC is a view-level pattern and has no bearing on the lower tiers of your application.
Ryan
I don't think this was worth down voting. Too much time has elapsed for me to up it one. Sorry George
used2could