views:

16

answers:

1

I've recently refactored my application with the following: Linq to SQL db connection Objects to wrap the linq to sql classes Mappers to map back and forth between objects and Linq to Sql entitys Service layer to call the repository, handing up objects to the UI.

Before I was just using Linq to SQL objects in my UI (I know). But when displaying relations it was so easy. For instance:

I have a able called SchoolProfile, and a table called School. A user has a SchoolProfile (with GPA, Rank, etc..) , which links to a School. The School adding functionality was easy - because it has no foreign keys.

When creating a form for a user to list all SchoolProfiles - they dont want to see a SchoolId. Before in my view it would simply be schoolprofile.School.Name. Now a ShoolProfile is a "flat" object in my ViewData with no properties. I guess I could create other classes to get the related data (name of the school, etc..) but that feels messy. Any suggestions?

+1  A: 

My suggestion is to look at ViewModels and AutoMapper. Basically you will create a specific ViewModel for your View and you can include SchoolName as a property of that ViewModel. Then you can use AutoMapper to map from your Domain Model (form Linq to Sql) to your ViewModel easily.

Basically, you want your View to get all the information it needs from the ViewModel. So design your ViewModel based on all the info you need to display. So all it needs to do is take what is in the ViewModel and spit it out.

Jeff T
Thats very interesting - I like the features of AutoMapper. Right now I don't want to bog down my app with 3'rd party tools (its still fairly simple) - but reading the documentation and watching some of the video gave me an idea. I'll just create properties for my objects that don't link to anything in linq to sql class directly. Then map them with my mappers - using the linq to sql property accessors. Thanks!
Jack

related questions