http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660You might want to also add the Obsolete attribute so that compiler warnings are issued when ViewData is used. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment26http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment26Mon, 12 Jan 2009 21:35:41 GMTOk, forget my comment, I've looked at the example code better note to myself: hit myself! http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment25http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment25Thu, 08 Jan 2009 13:21:32 GMT@Ayende, Can you provide then an example on how you retrieve the necessary data (model?) in the view? TIA http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment24http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment24Thu, 08 Jan 2009 13:18:32 GMTNicomm, We place ours in "Commons" assembly that can then be referenced by whoever (biz logic, data providers, UI views, web services proxies, rich clients that send/receive such DTO's via web services, etc.). Hence they remain "neutral" in an assembly that does not reference any System webform/winform/webservice/data namespaces. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment23http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment23Tue, 06 Jan 2009 17:59:12 GMTAaron, thanks for these nice explanations about DTOs usage. Just a question : in wich layer do you put your DTOs ? The domain layer, or the layer which contains the controllers ? I tend to put the DTOs in the domain layer, because it enables me to instantiate the DTOs directly from the DB, using NHibernate projections. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment22http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment22Tue, 06 Jan 2009 14:53:50 GMTAaron, Thanks for the response. I think we're on the same wavelength. We use DTO's everywhere: 1. Business Logic deals in DTO's. 2. Data Persistence Layer deals in DTO's and collections of. 3. NHibernate just maps DTO's to tables, etc. 4. Web Services "talk DTO's". 5. "Views" just render DTO's/collect information to fill DTO's. ActiveRecord is a no-go for us: our DTO's are consumed via web servcies from Java/PHP. Hence no way we will expose such crap like .Load/.Save! http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment21http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment21Fri, 02 Jan 2009 10:40:55 GMTripper, When I say entities I'm referring to DDD Entities. If you haven't read Eric Evan's DDD book, I'd highly suggest it. I'm not a fan of ActiveRecord--I use repositories, so no, I generally don't have load/save on my entities. Your head is in the right place though, the things persisted to the database are the things that should not be given to the view. DTOs are simply dumb objects. No real behavior, just getters/setters. It's not killing our app, it's just messy. It couples your domain to your views which isn't a good thing, especially when you're using brail and you don't have any compile time checking. The story is a bit better in Spark, but on the project i'm using Spark on there is a Application service/messaging boundary between the controller and the domain, so the controller won't ever even see an entity. andy, We used to use mapping classes, but they just seemed like a lot of overhead (interface/class/injection/etc) for what little they did. We now use extension methods (.ToDto() and such). We find that cleans up the syntax quite a bit and is lighter. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment20http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment20Fri, 02 Jan 2009 09:53:22 GMTdo you use for this conversion a object to object mapper or do you do it manually? Which mapper would you suggest? http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment19http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment19Wed, 31 Dec 2008 17:49:58 GMTBuggs, I would say it is the responsibility of the controller to do this conversion http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment18http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment18Wed, 31 Dec 2008 14:45:34 GMTInteresting discussion here guys. I'd love to see a simple example project of these concepts. So if you were building this blog page, there is a number of things to display, the blog entry, coments, blog stats, categories, archives etc. You'd probably end up with domain models like BlogEntry, Comment etc etc. Then you'd need a DTO say BlogShowDTO which would have a list of BlogEntryDTOs, list of CommentDTO etc? Does a service layer or repository pattern do the conversion between the domain model and DTOs, or does the controller do that? cheers http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment17http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment17Wed, 31 Dec 2008 14:32:31 GMTI have seen DTO and Entities referenced before as the same thing, DTO just has gets/sets? Entity has adidtional logic? Can also be ActiveRecord (load/save methods)? Can someone here explain the difference? Araron: "We started out with a small app and we passed entities to the views. We're now a big app and it's killing us". So what kind iof stuff is in your Entitiies that killed your app?! http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment16http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment16Wed, 31 Dec 2008 11:34:10 GMTRafael I agree with Aaron that the M in MVC is usually not a suitable domain model for medium to large size projects. Check out this great thread on the DDD-group for an in-depth discussion of this: [tech.groups.yahoo.com/.../9176](http://tech.groups.yahoo.com/group/domaindrivendesign/message/9176) http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment15http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment15Tue, 30 Dec 2008 08:18:00 GMTAaron, Trying to query for everything the view need usually means that you need to do a lot more work to give it exactly what it needs. I tend to pass view model objects that contains references to the entities. This allow me to chose how I want to deal with them, and yes, the views would use the model directly. That said, there are times when presentation concerns dictate that I wouldn't use the entities directly, because it is easier to get the data in another format, in which case I am all for it. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment14http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment14Tue, 30 Dec 2008 01:53:18 GMTRafalG, I usually go for (3), with the caveat that I watch for SELECT N +1 and optimize accordingly http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment13http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment13Tue, 30 Dec 2008 01:48:21 GMTRafal G, You don't have to agree with me. I'm just giving you my point of view based on the 3+ years of experience I have in working with a web MVC framework on a very large application. If you are using an ORM to map to a simple reporting database that is already formatted for display on views then no, I don't see a problem with this, and the answer to your original question would be to make sure that you join fetch the associations you need (assuming you're doing a master detail or tree view of some sort because otherwise you shouldn't be loading collections). I'd have to know the specifics of the view you're actually trying to create to tell you whether or not you're doing it wrong. I say it's a misconception because it *is* a misconception. If you are using an ORM to map your domain--your business domain you should *not* be giving them to your view. Business entities are for behaviors. Being displayed is not a behavior, it is a reporting concern. As for your hypothesis, there is nothing preventing you from keeping your session open during the view rendering. It's just a horrendously awful thing to do for multiple reasons. I know this because we used to do it. Your view should *not* be lazy loading anything, that's just leaky, hard to test and bad. Your view should also not do things like this: Order.OrderInfo.Customer.Name. If you want the customer's name, query for it. Ideally you give your view exactly what it needs to render without it having to do any deep digging. If you want to display customer name and order total, you don't give it Order. You give it a DTO or DataSet or whatever that has just those two things. Anything else is wasteful, leaky, hard to test, ugly, difficult for a designer working on your view to understand and just bad. Again, feel free to disagree/not listen to me/whatever Paul, I hear you. We started out with a small app and we passed entities to the views. We're now a big app and it's killing us. You can use something simple like a DataSet instead of a DTO if you're worried about DTO explosion. I personally wouldn't worry about this though. I've found that there really aren't any reasons to avoid having many DTOs--they don't need to be tested and they're easy to maintain. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment12http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment12Mon, 29 Dec 2008 23:57:25 GMTThis also helps catch really cool code errors like this one: if (String.IsNullOrEmpty(password)) { ModelState.AddModelError("password", "You must specify a password."); } if (ViewData.ModelState.IsValid) { ... The above code is lifted unchanged from the AccountController from the default project. You'll note that one is using ModelState directly and the other is using ViewData.ModelState. Now you might think that these would be linked to two different variables. They aren't. Controller.cs in asp.net mvc bits: public ModelStateDictionary ModelState { get { return ViewData.ModelState; } } So we're just typing out ViewData the second time for fun. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment11http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment11Mon, 29 Dec 2008 23:51:21 GMTAaron, I don't agree with you. I'm using OR mapper to build my data objects - in my application this is the model - the 'M' in 'MVC'. So views should be able to use it to do their work. I really don't see why you call this a 'misconception'. Are you trying to tell me that DAOs are not a proper 'Model' and I should build some other 'Model' suitable for views? Why? Because one model is too simple? Can you really tell my 'model' is bad without even seeing it? My hypothesis is that asp.net mvc is just 'incompatible' with OR mappers and that's why you and many others suggest that we can't use OR-mapped entities for model and must create some detached data structures instead. Why detached? Because data sessions are not allowed in views. Andy why aren't they allowed? I don't know - probably because of some religious approach to 'design patterns' forbidding use of any logic in views. This is very unnatural and counter-effective IMHO. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment10http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment10Mon, 29 Dec 2008 23:16:44 GMT@Aaron - It sounds like you are saying you should always use DTOs to pass data to the view (I may have misunderstood you, maybe it's just because your comment is strongly worded). Whilst I agree with the theoretical argument for using DTOs to represent messages to and from the view, how do you feel about only creating DTOs for views where the business model cannot be used directly due to say transformations or aggregations etc. It just seems to me unless the project demands complete architectural purity (e.g. it's a huge enterprise app) then a DTO explosion might not be the right thing for a typical small project. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment9http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment9Mon, 29 Dec 2008 23:14:17 GMTYour Model property is available in MS MVC vNext, isn't it? http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment8http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment8Mon, 29 Dec 2008 22:45:18 GMTRafalG, You should not give entities to your view. They do not belong there. Your view is a reporting concern and should be treated as such. Get the data from the database however you need to (projection queries from NHibernate, mapping from NHib entities, in memory cache, etc) and pass DTOs to your view. This is a common misconception about MVC, that your business model is the same model that you give the view. This is *not* the case and will lead to disaster and questions such as this. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment7http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment7Mon, 29 Dec 2008 22:38:43 GMTSince we're both digging in asp.net mvc, I've got a question. Suppose you have a view and a model. The model contains some data retrieved from database (let's use NHibernate). In the controller you retrieve a data record (let it be Order), put it into ViewData (or View.Model in your case) and want to display it. But you need to display more than just the record - you need to include also some information from objects referenced by Order, for example Order's items and ordering user's address. So you need to load the related objects from database. NHibernate would do that silently, but you are in a view - so the data session used in controller is already closed. How should such situation be handled? option 1 - pre-load everything in controller and use detached data only option 2 - open another data session in view option 3 - somehow share the session between controller & view I know option 1 is the preferred way, but it incurs a significant overhead (you need to manually do what OR-mappers can do automatically). Is (3) acceptable? http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment6http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment6Mon, 29 Dec 2008 20:00:02 GMTI prefer the MvcContrib's 'ScriptInclude' Also, there is a 'Stylesheet' http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment5http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment5Mon, 29 Dec 2008 19:54:19 GMTEl Guapo, You do notice how much MORE you have to write, right? And that this doesn't solve the problem of allow us to replace the implementation with contactenated script (reducing network round trips). http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment4http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment4Mon, 29 Dec 2008 19:18:11 GMTHmm it doesn't like my attempt at posting angle brackets. <script type="text/javascript" src="<%= Url.Content("~/Content/MicrosoftAjax.js") %> http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment3http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment3Mon, 29 Dec 2008 18:34:33 GMTOk, so how should the Title be set in the MVC world? I see your view markup, but that does not tell much. http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment2http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment2Mon, 29 Dec 2008 18:10:06 GMTWhy don't you want/need them? http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment1http://ayende.com/3778/my-baseline-asp-net-mvc-modifications#comment1Mon, 29 Dec 2008 17:59:32 GMT