Will Smith and I started an offline thread based on his post "Uninstalling EF Beta 3". Granted, the ADO.Net Entity Framework is still beta and probably won't go gold until Summer, but I wondered what he would use instead. His team is solid but not advanced and he wants to keep complexity to a minimum while remaining as agile as possible. Here's my advice. Your thoughts?
Update: 3/4/2008: Related, I'm recommending the Repository Factory guidance pattern. From the site:
You're probably wise in steering away from 3.5 stuff with an uninitiated staff. I'd probably encapsulate your data access leveraging the Enterprise Library Data Access Application Blocks. You could leverage CodeSmith and NetTiers to quickly generate the data access layer effectively shielding your less-advanced developers from the complexity (they simply call class library methods vs. code ADO.Net 2.0). Later, when you want to shift to ADO.Net Entity Framework or [less likely] LINQ to SQL, you can rip out this data access layer simply replacing it with EF or LINQ. Granted, [obviously] you'll have to adjust the consuming classes to leverage LINQ afterwards but it should be a less-invasive change.
Update: 3/4/2008: Related, I'm recommending the Repository Factory guidance pattern. From the site:
The Repository Factory is a guidance package that automates creation of entity classes that map to database tables and repository classes to read and write those entity classes. The generated code removes the tedium of writing a persistence-ignorant domain model.
This package was originally published as the "Data Access Guidance Package" as part of the Web Service Software Factory. Data access is a much larger problem space than just services, so we've decided to split this package out into its own project.
Comments