Carpool Project: Part #3

My first question was “where do I put the POCOs?” I can put them in the Models folder in the MVC solution – there is already a ChangePassword, Logon, and Register Model there. They are all POCOs with some validation attributes added.

However, those Models only exist in context of the MVC application – they are not in the Domain. Therefore, I am leaning to putting the Domain POCOs in the Domain Layer (as recommended in DDD). I then realized I could use the Layering diagram in VS2010 – Yippie!

I note that the data layer is not abstract enough – rather it is the implementation. I just didn’t know what to call it

My next big thought – do I add validation attributes to POCOs? Without actually trying anything, I learned towards yes – so I can get the built in features of MVC validation.

I then went back and removed the class name from the properties (CarPoolId is now Id, etc…) to make the code more readable.

My next dilemma has to do with dependency properties. Consider this class:

 1     public class SwimmerSummary
 2     {
 3         public int SwimmerId { get; set; }
 4         public string SwimmerName { get; set; }
 5         public int SwimGroupId { get; set; }
 6         public string SwimGroupName { get; set; }
 7         public int SwimTeamId { get; set; }
 8         public string SwimTeamName { get; set; }
 9     }
10  

I want to assign the Swimmer Group on the UI, perhaps change the name, perhaps assign a new team. The problem is that I run the risk of changing the Swim Team and Swim Group to an invalid state. I can limit the Update to group and put the swim team name into the swim group name, but that is not what I want. Do I need to check the group and team on each update and make sure that it is valid? I think yes – that is what the factory can do…

I then thought about how I want to signal that the ViewModels are valid. I realized the pattern that Rob and I used on another project will work well. I inherit from a base class that has 2 properties: IsValid and List<Errors> that can be traversed.

I wondered then if I needed two validation mechanisms: using attributes on the properties and then using this IsValid pattern. I think the answer is yes – you can signal to the UI the required length and IsNull validation via the attributes, but then you also can have a return on every CRUD to say if the class is OK.

Note that I have not tested anything yet – there is nothing to test. Testing getters and setters without any custom logic is testing the .NET framework – which is a waste of time. My code coverage is 0, but that is fine.

I now have enough of my Domain Model conceptualized to set up a backing store.  In this case, a SQL Server 2008 database.  Since a picture can say a thousand words:

Once the database was done, I set up my Entity Framework Model:

My data layer was then setup well enough to continue into the business layer…