Bob and others.... Trust me, the Entity Framework won't even come close to iBATIS. Here is some information I can share (because it's already public):
1) The entity framework is a HUGE abstraction on top of your database. It's literally another layer. Databases have various layers including the physical layer (files on disk, tablespaces, spans etc.). The logical layer, which is your relational table model and the thing you write SQL against. The next layer is the conceptual layer, which today you'd only know as the first diagram you draw when thinking about a new database design. For example, an ERD without bridge tables might be an example of a conceptual diagram. Or, more common, the classes you map to relational databases today are good examples of conceptual models. The Entity Framework makes that conceptual layer real at the database level itself. It sits between your classes and tables with its own schema or model if you will. So you might have an Employee class, an Employee table and an Employee Entity in between. It's a layer of abstraction -- a HUGE layer of abstraction. 2) In implementation, it is in fact closer to NHibernate than it is to iBATIS and therefore "threatens" hibernate more. It's an Object Relational Mapper that exposes more of its guts than most do. As a result, it suffers all of the same consequences of any Object Relational Mapper -- all of the very problems iBATIS seeks to solve. 3) As an ORM, the Entity Framework struck me as EXTREMELY overcomplicated. In the original implementation it took 4 XML files to map any given class to any given table. Microsoft's plan to aleviate this was to offer tools to generate and maintain the XML files....we all know how that goes. Furthermore, it's basically impossible to use the Entity Framework with LINQ without generating code. LINQ to Entities requires that you generate a LINQ compatible database abstraction that you can query against. This is sort of obvious, as LINQ needs real symbols (class names and field names) to work against...it doesn't work against strings. So far you're dealing with the Entity definition XML that is best generated/created with a tool, mapping files which are best created with a tool, and generated C# code that can only be generated by a tool unless you can type as fast as the android Data from STNG fame. ;-) Sound familiar? Anyone who has been a J2EE developer will have nightmarish flashbacks to EJB2. The Entity Framework strikes me as the EntityBeans of the .NET world. If you go read the EntityBean chapters from Mastering Enterprise JavaBeans from Ed Roman, then go read the Entity Framework whitepapers from Microsoft's site, and download the demo pack, you'll understand exactly what I mean. In my opinion Microsoft is making a huge mistake with the Entity Framework. I won't even get into the politics of who maintains the conceptual model...the developers or the DBA... ;-) iBATIS has absolutely nothing to worry about. DLINQ is more likely to win over some iBATIS hearts based strictly on the simplicity of DLINQ. But that simplicity is also a weakness of DLINQ as it too is an ORM, but not as good as NHibernate and not even in the same class as iBATIS. Cheers, Clinton On 1/31/07, Bob Hanson <[EMAIL PROTECTED]> wrote:
http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx Will the ADO.NET Entity framework make iBATIS.NET obsolete? It appears that it will provide the same type of mapping framework as iBATIS while also providing tools for mapping and code generation. Throw in LINQ to Entities and it would seem that MS will provide a framework that would be equivalent to iBATIS plus LINQ to iBATIS (assuming the latter was eventually written). Thoughts?
