This project is read-only.

Models in WCHM vs Sharp?

May 5, 2010 at 4:55 AM
Edited May 5, 2010 at 5:07 AM

I am using many sample apps to compare how different groups address the issue of architecting a ASP.NET MVC web app. One thing I noticed is that, in Sharp, there are no distinct Models per se, as can be found in the standard MVC2 template or in your sample architecture (ViewModels, FormModels and Mappers). Sharp seems to pull in a Repository inside a Controller and pull data from it into the View. In your case, you map from Tasks into a ViewModel.

Two questions:

  • Why the difference? Any pros or cons either way? Or, IOW, is there an actual design decision, or it just ended up that way?
  • Why just break out the V from the MVC, so that you end up with the WhoCanHelpMe.Web.Controllers namespace for the "MC" and WhoCanHelpMe.Web for the "V"? Why not further breakup Web.Controllers into M and C separates?

I appreciate any who can help me... ;)

May 5, 2010 at 2:47 PM

sharp has a really basic and unrealistic example.  real world apps require a lot more abstraction.  i recommend you look at the whocanhelpme codeplex home and review the architectural overview and also look at who can help me FAQ.  hopefully that helps you.

May 6, 2010 at 4:03 AM

Thanks. I have read all that material at this point, but unfortunately none of it seems to address the curiosity questions I posed above. I can blissfully go on and use WCHM as-is, but I tend to ask lots of "why" questions which help me understand things a little more deeply than connecting lines of code. :)



May 6, 2010 at 11:44 AM
Edited May 6, 2010 at 1:53 PM

In WCHM - we put together a real world architecture based on a MVC project we built last year - it was much, much larger than WCHM (6 devs working for 6 months). We came up with architecture to give the best testability, reusability and separation of concerns we could using this technology stack. We think it worked out rather well.

Architecturally - we're of the opinion that you should not have repositories in controllers - because your business logic (or infrastructure logic) is now in your presentation layer - your presentation layer should literally only recieve input, decide an action, and decide what view to display as a result of that action. This leaves your controller very thin, and very testable. Make them do one thing only and do it well.

For us the presentation layer is the combination of view engine and controller (hence why they are in the presentation solution folder) - VM are purely a dto for sending data to the view to be rendered - nothing else - the Model - is our Domain Model - which I guess is where we diverge from MS's boilerplate MVC architecture and use concepts from Domain Driven Design.

The Tasks layer is really where reusable logic sits - this is essentially an orchestration layer - where you would write a series of tasks, doing business logic, data access, external service calls etc. Mappers are used to keep the boundaries clean.

Hope this info helps - post again if you need any more clarifications or you think I've missed some point.