I'm trying to implement a highly reusable web system where the source of data for the model can be changed at will. What I need is a generic type instead of relying on the type generated by either LINQ or entities.
This tutorial goes over separation for high reusability but what happens if the data representation between entities and LINQ changes ever so slightly? Then you'd have to change the view. Are the classes generated by LINQ and entities guaranteed to be the same for when they're passed to the view? Is it possible to create a class/interface that generically represents the data?
EXAMPLE
namespace Intranet.Areas.Accounts.ViewModels
{
using Intranet.Areas.Accounts;
using System.Collections.Generic;
using Intranet.Areas.Accounts.Models;
public class ContractsControlViewData
{
public IEnumerable<Contract> Contracts { get; set; }
public IEnumerable<tblCC_Contract_CC> tblCC_Contract_CCs { get; set; }
public IEnumerable<tblCC_Contract_Data_Terminal> tblCC_Contract_Data_Terminals { get; set; }
public IEnumerable<tblCC_CDT_Data_Service> tblCC_CDT_Data_Services { get; set; }
public IEnumerable<tblCC_Data_Service> tblCC_Data_Services { get; set; }
}
}
The above code is taken from a small project I'm testing. Notice that I've got types that begin with "tbl". I've just dragged these on from a database onto the LINQ designer and I'm using them in this container which is passed to the view to later render multiple result sets on screen.
The problem is that if I ditch LINQ and use entities instead, will the data still be reflected in the same way as the types represented here? Will Contract still be valid? Bear in mind that these types in the previous code example are generated by LINQ. How consistent are they if you use a different data access technology?
This is why I wonder if we should, for separation of concerns, and for consistency of data instead create our own classes to represent the data in a consistent manner.
My brain hurts, someone save me from myself.