views:

1711

answers:

6

Greetings,

Apologies in advance that I have not researched this toughly enough to answer the question myself, but I imagine it would take me some time and I would rather know now before I invest more time in learning it. I couldn't find anything in my initial research..

Why use ASP.Net MVC if your already using a multi-tier architecture (Data Layer, Logic Layer, Presentation Layer)? Other than the fact the controller has more power than the logic layer.

Am I right in thinking I can use nHibernate and all my data access classes, entities, and mappings in the Model part of the MVC?

When using controllers, is it best to separate a lot of the logic into a separate class so I can call it from multiple controllers? Or can I call them from the controllers themselves, considering the fact that I would not want all of them to be Actions, just normal methods.

Thanks

+7  A: 

Hi, MVC is not to replace N-Tier, it is a way to organize the presentation layer.

I would not say that the controller is more powerful than the logic layer. Instead, the controller (as a part of the presentation layer) should still call the logic layer.

Controllers should only prepare data for views and handle actions from views. You should still use your BLL.

gius
+2  A: 

Yes, NHibernate entities can (and they should be) be passed to the views.

This will you get you into some trouble. You should use flattened, null-safe DTOs a.k.a. view models.

Matt Hinze
...my mistake. I meant POCO entites (as a data carrier) rather than NHibernate entities.
gius
Erm, NHibernate entities can and should be POCOs
Anthony
But you can use them to edit database (Save, Delete, etc.) from the view, which is not good. - Or is the mentioned trouble anywhere else?
gius
The immediate trouble is mostly with null safety and occasionally ORM-related issues like SELECT N+1. There are other concerns, related to security, testing, and data integrity, that lead some architects to avoid using the domain model as the M in MVC, and instead use a view model.
Matt Hinze
+2  A: 

Damien, you might want to read these 2 posts:

The Fat Controller

An Architectural View of the ASP.NET MVC Framework

rodbv
A: 

To answer your question on why use if you are already going multi-tier is that it makes for more organized and search-engine friendly URL's. Also, it is more of a standard pattern than the other patterns tend to be in ASP.Net. That makes it more developer friendly for those that are already using MVC on other platforms.

Turnkey
A: 

Thanks for the anwsers so far! :)

Regarding using n- tier, Do I put mappings and classes in the model part? And do I put my business classes in the same folder as the controllers or in a normal folder

Are the layers:

  • view
  • business logic
  • data access

With the controllers doing the actions?

I mean there is some crossover..

Damien
I would put very little code in the controller, and nothing but controllers in the controller folder. All the business logic, data access etc I would have in the model folder, in case of a small app, or in a separate project altogether in case of a bigger app.
rodbv
Why the model, if the Business logic is not data should I not put it in it's own folder?
Damien
Please read these posts on "onion architecture". I think they will be helpful. http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Matt Hinze
A: 

N-tier is an archtitectual pattern, to enable reuse, seperaation of concerns and scalability of the key areas of your application. The non UI layers (Business, Data, Facade etc.) should be unit tested and UI agnostic.

The UI layer is just one of these layers weather it be Silverlight, ASP.NET MVC, web forms etc.

MVC, like MVP is a design pattern that enables better testability of the UI Layer. ASP.Net MVC is an out of the box framework that supports and enforces this pattern. The pattern was arround an in use long before this framework.

But this is simply a UI layer choice, There should be no interaction with databases, services etc in the controllers, they control the state of the view using the model, Should not control the business logic, peresistence, transactions etc.

En