Allow me to describe my current development scenario:

1. We have a mainframe legacy application supporting management of insurance benefits and claims. The data model supporting this app is pretty static. There is a 1.1/2.0 portal on the front-end that makes this application available to various call centers. This portal is fed by a 2.0 remoting services solution.

2. We have a third party VB6/SQL Server app supporting more modern, flexible/adaptable benefits and claims. The data model supporting this application is still evolving, and we won't have a final version until late September, perhaps October, of this year. One goal is to tie this new app into the service portal seamlessly -- the client app won't know whether it's interrogating the mainframe or the SQL Server datastore. Again, the portal will be fed by the 2.0 remoting services layer.

Both applications are already live; #1 supports most production operations, #2 is introducing some new production operations, and will gradually take over the legacy operations. So, with both apps live, and the data model behind #2 shifting, we're trying to not only abstract the underlying implementation within the remoting services layer away from the portal client, but abstract it in a way that the changing data model has a minimal impact on the rest of the system/requires minimal work to adapt when the data model changes are accepted.

Now, I'm no Entity Framework or LINQ expert, but from what I know/have heard/have seen/have read, it seems to me, especially with SQLMetal's visual designer, that it would be easier to create this abstraction against Entities, than it would be against an evolving DAL to support an evolving data model.

Am I way off on this I'll admit, a large part of my motivation to use Entities comes from a simple desire to use 3.0, but it seems to me that there might be a real case to be made here to my higher-ups.

Re: ADO.NET (Pre-release) Are Entities the Answer?

Brian - MSFT

First off, letĄŻs start by giving a brief overview of what is the ADO.NET Entity Framework then we can talk about how helps you. The framework is the DAL and isnĄŻt part of the actual database. I think you understand the problem quite well. Some databases are well designed, others not, while still some are designed for storage and optimization, making the database harder to program against. While in your case the model is ever changing.

EDM puts a layer of abstraction on top the database. There are three layers to EDM. The lowest layer is the logical layer, basically a better view of the database structure. You can add native sql or just entity to table mapping. On top, you have the conceptual layer, which builds up the view you want to have on your database; this view supports inheritance, complex types, relationships, Ą­. For example, this layer allows you to create a Customer entity with all of the appropriate properties without having to worry about a bunch of joins. Then we have a middle layer which maps between the conceptual EDM and the logical EDM. As an addition, we support SPROC and views. Think about that, you can have a Customer which comes from a SPROC or gets updated with a SPROC, and the programmer doesnĄŻt even need to know. ADO.NET Entity Framework implements EDM.

Now that we have the layer defined, letĄŻs apply this to your problem. If you have a LOB app that is based on the conceptual layer, meaning a Customer is a Customer no matter how itĄŻs normalized in the database, then you have the ever changing database, well parts of the underlying logical layer can change without changing the conceptual layer.

HereĄŻs a resource with more info to help understand. I hope this give you some direction to look into. Also, the ADO.NET Entity Framework is supported in v3.5.