0

I'm moving from web forms to MVC and I'm a little lost. My question was almost answered by MVC Vs n-tier architecture but not quite.

In web forms, I would typically build my site with 3 projects under my solution; UI, BLL and DAL and maybe one for tests (I believe this is common practice).

Now I'm starting MVC3 and it appears I don't need to separate the 3 based upon how Visual Studio lays it out for me.

Is MVC designed to run over multiple projects or should it run from just one project? Web forms seems to suit an N-Tier application and although I could probably make my MVC N-Tier by deleting my Models folder and moving that to my DAL and deleting my Controller folder and moving that to my BLL it seems as if I'm fighting what MVC wants me to do (or maybe just how Visual Studio sets it up)? Or maybe keep the Model and Controller as they are, but create a 'viewmodel' in the Model folder and the Controller talks to the BLL for most of the logic? Any pointers would be great.

Community
  • 1
  • 1
Dave
  • 8,163
  • 11
  • 67
  • 103

2 Answers2

3

MVC is a presentation pattern only, thus it only says how you should structure your presentation logic. It doesn't say anything about data access patterns nor how you structure your business domain.

I tend to structure my web apps in a web-project (MVC), a models (domain) project, and maybe a data access and/or services project depending on the app. I always delete my Models-folder in the web project as I don't want any of that there. All my domain models and view models live in the models project.

Regarding the controllers, a controller should only be a translator for what the user wants to do (the request) so the model and view can respond accordingly (the response). I.e. the controller should be so thin that you barely notice it. The controller should contain logic for choosing the model and what view to display. All other logic belongs in the model.

In addition, the view should only contain very simple presentation logic like ifs and foreaches, but the conditions should be prepared in the view model.

Rickard
  • 2,325
  • 13
  • 22
  • Ah, I had never realized that... This makes more sense but it still feels as if it doesn't separate concerns very well... I can understand how to set up the Models and have a separate DAL but the Controller section seems very tied in to the UI! – Dave Feb 15 '13 at 11:51
1

The MVC model is for UI only. You can continue using the same separation of concern as before.

In our project, we keep the web site layer and the view models in the web project. We use WCF services for data access (this would correspond to your DAL). Bridging the gap is a logic project (this would correspond to your business logic) that contains the client side access to the services and any translations that need to occur from the service results to the view models.

Both our controllers and view models are very thin. Logic is in the logic layer and in the domain models that are kept separate. We typically would share domain models between service contracts (in your case, DAL) and the view models, but the view model is never directly exposing the domain model.

I hope this helps.

gabnaim
  • 1,103
  • 9
  • 13
  • Thank you. MVC does though appear to really couple the role of coders and developers - at least with web forms you could keep the 'HTML' page relatively free from code! – Dave Feb 20 '13 at 10:04
  • The strength of MVC is that HTML page is relatively free of code. Your model should have everything what the UI needs. Our view would have logic like foreach loops to create a table, or show a section based on a flag in the model. Anything else should go into the controllers/model. On our project we have designers do the HTML and the "coders" copy the prototypes and alter the HTML as needed for MVC. BTW you can use MVC with web forms. – gabnaim Feb 20 '13 at 15:40