Practical .NET
With ASP.NET MVC and Data Transfer Objects, The Bigger the Better
Create the best object for moving data from your Controller to your View.
In ASP.NET MVC, the Controller is responsible for manipulating your business objects to retrieve the data to display to the user in a View. Since the typical View requires data from several business entities, you need to combine data from several sources into a Data Transfer Object (DTO) to pass the data from the Controller to the View.
One solution is to create a DTO with just enough properties to hold the data that the View needs. This class, for example, combines Customer information with SalesOrder information for a View that displays a SalesOrder-with-some-Customer-data:
Public Class CustOrderDTO
Public Property CustomerId As String
Public Property CustomerName As String
Public Property CustomerAddress As Address
Public Property SalesOrderId As String
Public Property DeliveryDate As DateTime
'...more SalesOrder properties...
End Class
Of course, filling all of those properties is going to require a lot of assignment statements (though using Automapper can help here).
You're better off to follow the model of the CustomerAddress property in my sample DTO which holds a whole Address object rather than having individual street, city, etc. fields. Rather than having lots of individual fields, just put the whole Customer and SalesOrder object in your DTO:
Public Class CustOrderDTO
Public Property Cust As Customer
Public Property SOrder As SalesOrder
End Class
There's no real cost to this approach: It will take you just as long to retrieve the whole Customer object as to retrieve two or three properties (assuming you're not retrieving any BLOB fields or your Customer object doesn't have hundreds of properties). Furthermore, the code in your Controller to fill your DTO could shrink to as little as this:
Dim cDTO As New CustOrderDTO
cDTO.Customer = CustomerFactory.GetCustomerById(custId)
cDTO.SalesOrder = OrderFactory.GetOrderById(SoId)
And, as I discuss elsewhere, with the right LINQ statement and navigation properties in place, your code might get simpler yet.
There are other benefits. I bet, for example, the first request you get after rolling out this application is to add some Customer-related data to the View. Since you're already moving that data to the View all you have to do is add some more HTML to your View. This DTO is also more likely to be useful on other views (a View that displays Customer information with some SalesOrder data).
When I propose this to my clients I occasionally get some objections that "I'm moving these huge objects around." I'm not, of course: The .NET Framework just moves around references to my Customer, SalesOrder, and CustOrderDTO objects – there's only one copy of each object in memory at any time.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.