Pregled posta

Adresa bloga: https://blog.dnevnik.hr/rcosic

Marketing

ORM of the Future (ADO.NET Entity Framework)

And now, let me finish with the lamment. After presenting NHibernate and LINQ, I will try to write sth about ADO.NET Entity Framework. Here it is:

Entity Framework: LINQ to Entities

King is dead! Long live the king!
Well, LINQ is not exactly dead as we are not dead as majority of developers today still use 2.0 fx and 3.5, thus it is still bleeding-edge technology (although the wispers of 4.0 can be felt in the waters). BUT, the future ORM (and more!) is gonna be here soon.

The ADO.NET Entity Framework, part of the ADO.NET components of the .NET Framework, is a framework for providing services on data models from Microsoft. Although an object-relational mapping service is an important part of it, it aims to provide more services such as query, view and reporting services. It is geared towards solving the mismatch between the formats in which data is stored in a database and in which it is consumed in an object-oriented programming language or other front ends.

ADO.NET Entity Framework is included with .NET Framework 3.5 Service Pack 1 and Visual Studio 2008 Service Pack 1, released on 11 Aug 2008. It also includes the capability of executing LINQ against ADO.NET Entity Framework entities.



The architecture of the ADO.NET Entity Framework, from the bottom up, consists of the following:


  • Data source specific providers, which abstracts the ADO.NET interfaces to connect to the database when programming against the conceptual schema.

  • Map provider, a database-specific provider that translates the Entity SQL command tree into a query in the native SQL flavor of the database. It includes the Store specific bridge, which is the component that is responsible for translating the generic command tree into a store-specific command tree.

  • EDM parser and view mapping, which takes the SDL specification of the data model and how it maps onto the underlying relational model and enables programming against the conceptual model. From the relational schema, it creates views of the data corresponding to the conceptual model. It aggregates information from multiple tables in order to aggregate them into an entity, and splits an update to an entity into multiple updates to whichever table contributed to that entity.

  • Query and update pipeline, processes queries, filters and update-requests to convert them into canonical command trees which are then converted into store-specific queries by the map provider.

  • Metadata services, which handle all metadata related to entities, relationships and mappings.

  • Transactions, to integrate with transactional capabilities of the underlying store. If the underlying store does not support transactions, support for it needs to be implemented at this layer.

  • Conceptual layer API, the runtime that exposes the programming model for coding against the conceptual schema. It follows the ADO.NET pattern of using Connection objects to refer to the map provider, using Command objects to send the query, and returning EntityResultSets or EntitySets containing the result.
    Disconnected components, which locally caches datasets and entity sets for using the ADO.NET Entity Framework in an occasionally connected environment.
    Embedded database: ADO.NET Entity Framework includes a lightweight embedded database for client-side caching and querying of relational data.

  • Design tools, such as Mapping Designer are also included with ADO.NET Entity Framework which simplifies the job on mapping a conceptual schema to the relational schema and specifying which properties of an entity type correspond to which table in the database.

  • Programming layers, which exposes the EDM as programming constructs which can be consumed by programming languages.

  • Object services, automatically generate code for CLR classes that expose the same properties as an entity, thus enabling instantiation of entities as .NET objects.

  • Web services, which expose entities as web services.

  • High level services, such as reporting services which work on entities rather than relational data.



An Entity Framework application requires creating a conceptual model defining the entities and relationships, a logical model that represents the underlying relational model, and the mappings between the two. A programmable object model is then generated from the conceptual model.

Entity Data Model Tools

The Entity Data Model (EDM) is a model for defining data as sets of entities and relationships to which common language runtime (CLR) types and storage structures can be mapped. The EDM enables developers to program against a conceptual data model instead of directly against a storage schema.

There are three tools that are designed to help you graphically build applications with the EDM: the Entity Data Model Wizard, the ADO.NET Entity Data Model Designer (Entity Designer), and the Update Model Wizard. These tools work together to help you generate, edit, and update an EDM, as follows:

Entity Data Model Wizard allows you to generate an EDM from an existing database, add database connection information to the application, and generate C# or Visual Basic classes based on the conceptual model. When the Entity Data Model Wizard finishes generating an EDM, it launches the Entity Designer.

Entity Designer allows you to visually create and modify entities, associations, mappings, and inheritance relationships. You can also validate an EDM with the Entity Designer.

Update Model Wizard allows you to update an EDM when changes have been made to the underlying database. You must launch this tool from within the Entity Designer.

There is also a command-line tool designed to help you build applications with the EDM: the EdmGen.exe tool. This tool can generate an EDM, validate an existing model, produce source code files that contain object classes based on the conceptual model, and produce source code files that contain views generated by the model.

So, what to choose?

Well, I can't aswer you on that. In fact, some of partners I work with have built their own application architecture on that. And they did it quite well. But the question arises - aren't ADO.NET Entity Framework gonna swept them soon? Well, I can't answer on it also. Maybe they coded it so well and crafted for them so suitable that they won't be in need to use something else. But, from my own experience, I know that most of the dev-companies haven't any idea about what it is and how to use it.

Would they crash and stumble? Nah! But did they picked the right track?

We'll see....



Post je objavljen 25.10.2008. u 08:16 sati.