For my whole software development career I’ve been focused on the enterprise app dev space. (I did try to join the Zune team at one point, but that’s the topic of another post ;) While some people baulk at the term “enterprise” it does actually carry certain connotations to many of us. This blog entry is an inquiry - a checkpoint if you will - into that space to see if things have changed recently.
One of the things that has been consistent in almost all of the enterprise implementations I’ve written and seen customer write is the assurance that custom code be very separated from vendor technology. When you have millions of dollars invested in a [multi-year] solution, the last thing you want is for a vendor that you’ve taken a dependency on (yes, Microsoft is a vendor in this context) to change something that causes an unexpected investment in revisions.
Don, where are you going with this?
Well, I’m in the process of starting a guidance project that deals with data access – specifically, using the latest Microsoft data access technologies. Since the patterns & practices team focuses primary on enterprise scenarios, to me, this means “how to build the most appropriate data access layer (DAL) for your scenario.” (as always, please correct me if I should think about this differently)
In preparation for this guidance project, I’m going through and trying to get smart about things like LINQ to SQL, the ADO.NET Entity Framework, and what it means to use them to build a DAL. In the process, it looks like the creators of these technologies expect the developers (you) to NOT isolate their code from vendor code (LINQ to SQL is integrated into the actual C# and VB.NET languages and EF expects you to use the entity classes directly from your business logic).
So my question is … are you okay with this? In using LINQ to SQL and/or EF, are you okay with the dependencies you have to take in your DAL or are you jumping through hoops trying to avoid it?
Of course I’m mostly asking to try to assess what you would expect from the guidance. Thanks for your help.