Dev Link2009 Asp Net Mvc Pattern And Ani Patterns Chris Hefley
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
Editor's Notes
Hi everyone, thanks for coming. This is ASP.NET MVC: Patterns and AntiPatterns, and I’m Chris Hefley. You’ll often see a talk like this one labeled as “Asp.Net MVC Best Practices”, but I intentionally stayed away from that formulation. I don’t really like the use of the term “Best Practices” most of the time, because it’s usually being used by someone who wants to sound authoritative about something they don’t understand well enough to explain why they feel the way they do about it.These are things I’ve found useful, and of course this is all “in my opinion”, but I’ll do my best to explain why each of the items we’ll cover is considered good or bad. This is not an introduction to ASP.Net MVC, but…since this is the only ASP.Net MVC talk here this year, I’m going to spend exactly one slide on explaining how MVC works, so that any of you are completely new to it may have a chance of remembering some of these things once you do get more familiar with it.
Ok, now on with the show.
When you hear talk about an “Anemic Domain Model”, it’s referring to a domain model that is almost all data and no behavior, such that all the behavior of the system is captured in some other layer, like a service layer or worse, in the presentation layer. That’s bad. An anemic controller, however is Good. Just like it’s a bad idea to put domain logic in your code-behind pages in web forms, it’s not a good idea to fill your controllers with that kind of logic either. Your controller actions should just call methods on some service layer or domain layer class, prepare any view models you are using (more on that later), and render the ViewResult or other ActionResult as needed. Think of them almost like Event handlers. They capture the incoming request, bind to the ViewModel passed back from the view, and pass that model on to another layer for processing.I like to find an illustrative image for these patterns, but when I googled “Skinny Controller, Fat Model” the results I got, while very illustrative of the point, were not really appropriate for display in a public forum.
Why? Because it will cause bugs in your code later. Expensive, hard to find bugs.
And this bit of code leads us right into our next pattern…
Don’t use ViewData[“key”] and don’t explicitly assign ViewData.model = model; Instead, use strongly typed views, and return View(model);For things like ViewData[“ErrorMessage”], create a base class for your ViewModel, that has properties like string ErrorMessage; etc.
Don’t use ViewData[“key”] and don’t explicitly assign ViewData.model = model; Instead, use strongly typed views, and return View(model);For things like ViewData[“ErrorMessage”], create a base class for your ViewModel, that has properties like string ErrorMessage; etc.
Don’t use ViewData[“key”] and don’t explicitly assign ViewData.model = model; Instead, use strongly typed views, and return View(model);For things like ViewData[“ErrorMessage”], create a base class for your ViewModel, that has properties like string ErrorMessage; etc.
User interface segregation principle insteadShow code: IUserContextShow Code: one-off-view-model
MvcContrib comes with ControllerFactories for several of the most popular IOC containers
MvcContrib comes with ControllerFactories for several of the most popular IOC containers