Carpool Project: Part #9

I started with the View a bit more and I ran into an issue that cuts to the heart of D3 and SOC. On my Carpool page, I want a grid of all practices that are associated with the car pool (usually 1, but could be more). In the view, I wrote this (headers omitted for brevity):

 1     <% foreach (Com.Tff.Carpool.Domain.Practice practice in Model.Practices)
 2        { %>
 3         <tr>
 4             <td>
 5                 <%: practice.Id%>
 6             </td>
 7             <td>
 8                 <%: practice.Date%>
 9             </td>
10             <td>
11                 <%: practice.DryLandIndicator%>
12             </td>
13             <td>
14                 <%: practice.EndTime%>
15             </td>
16             <td>
17                 <%: practice.StartTime%>
18             </td>
19             <td>
20                 <% foreach (Com.Tff.Carpool.Domain.SwimGroup swimGroup in practice.SwimGroups)
21                 { %>
22                     <%: swimGroup.Name%>
23                 <% } %>
24             </td>
25             <td>
26                 <%: Html.ActionLink("Edit", "Edit", new { practiceId = practice.Id })%>
27                 <%: Html.ActionLink("Delete", "Delete", new { PracticeId = practice.Id })%>
28             </td>
29         </tr>
30 
31     <% } %>
32  

And it comes out with the expected HTML:

Notice how the Swim Group is joined together using that secondary loop. This got me thinking, part of the reason I crated the ViewModel POCOs was to do this kind of flattening. If the UI can handle it easily, why not use EF-enabled POCOs and save the who Domain Layer step of mapping the EF Classes to the POCO ones? If all I had to worry about was the flattening of Swim Groups to practices, perhaps writing that join in the UI is better than the Domain Layer. Then I thought – NO. The domain layer should be responsible for serving objects, even if the UI can handle it. I would say that is analogous to “we can put the code in the code-behind in Web Forms.” Eventually, the code needs to be written – so I would rather have it in the Domain layer where I have exact control and can add in any custom logic. If any custom logic for the flattening happens, the UI will quickly become a morass of spaghetti. On a side note, I find writing C# is much much better than writing WebForms View Engine code – those gators drive me nuts.

Saying that, I realized I don’t need a carpool controller, I need a CarpoolSummary controller and view -> for the simple reason that Carpools don’t have PracticeSummaries – CarpoolSummaries do. Time to do some re-writing!