You can write your own control that can bind as you wish to be used this way (I made one of them):
<ItemTemplate> <%# Eval("MainContact.FirstName")%> </ItemTemplate> <EditItemTemplate> <xx:BinderHelper runat="server" DataSource='<%# Bind("MainContact") %>'> <ItemTemplate> <asp:TextBox Text='<%# Bind("FirstName") %>' ID="txtFirstName" runat="server" /> </ItemTemplate> </xx:BinderHelper> </EditItemTemplate>
In any case, I suggest that you do not use domain objects directly on the pages, but generally do not write them with ObjectDataSource . The problem is that when you change your domain, for example, to add a field:
public class Person { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; }
Then you will need to change all GridViews, FormViews, etc., to save BirthDate, otherwise the infrastructure will call the ObjectDataSource Update method, putting null in BirthDate. For example:
<asp:GridView runat="server" DataSourceID="odsForm" AutoGenerateColumns="False"> <Columns> <asp:CommandField runat="server" ShowEditButton="True" /> <asp:BoundField DataField="FirstName" /> <asp:BoundField DataField="LastName" /> </Columns> </asp:GridView>
It will read your faces from the database. Each person will have a date of birth. When you save, the person will be updated using BirthDate to null , because the GridView does not save the new field.
I think the best solution is to write a DTO to bind the data (and leave it in the Presentation layer) and DataObjects. In your case:
public class EntryItemView { public int Id { get; set; } public string Email { get; set; } public string Password { get; set; } public string MainContactFirstName { get; set; } } [DataObject] public class EntryItemViewDataObject { [DataObjectMethod(DataObjectMethodType.Select)] public EntryItemView GetItem(...) {
Thus, any addition to your domain will be safe for your views, and DataObjects will only read / write the fields that they need.