{"id":6543,"date":"2008-03-06T16:31:00","date_gmt":"2008-03-07T00:31:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/dataplatforminsider\/2008\/03\/06\/entities-entities-entities\/"},"modified":"2024-01-22T22:51:47","modified_gmt":"2024-01-23T06:51:47","slug":"entities-entities-entities","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2008\/03\/06\/entities-entities-entities\/","title":{"rendered":"entities, Entities, ENTITIES!"},"content":{"rendered":"

It’s getting louder<\/strong><\/p>\n

If you’ve been following Microsoft’s efforts around data programmability, you’ll have inevitably heard a thing or two about “entities”. Specifically, the Entity Data Model (EDM) and the ADO.NET Entity Framework (EF). These technologies lay the groundwork for major advancements in how developers build data-centric applications and for empowering DBA’s to manage databases more freely. One could argue, the EDM and EF are triggering a paradigm shift in database development.<\/p>\n

What’s the problem?<\/strong><\/p>\n

Traditionally, database developers have had to bridge two worlds: application development and database management. These are relatively easy worlds to manage when building small or single user applications, however, things quickly become complicated as data grows and as more applications need access to the same information. In such complex environments, changes to the underlying databases may need to be synchronized across multiple applications that access this information and across several teams that are responsible for maintaining those applications. DBA’s and developers have to proceed in lock-step to properly reflect\u00a0changes\/improvements to both applications and databases.<\/p>\n

Entities\u00a0to the rescue<\/strong><\/p>\n

The Entity Data Model and ADO.NET Entity Framework were designed to address this application\/database divide and, along the way,\u00a0improve how database applications are designed and developed. Entities are essentially a conceptual representation of information (e.g. Customer entity) that is mapped to underlying databases objects (e.g. CustomersMaster, CustomerDetail, CustomerOrders, CustomerHistory tables). This allows developers to efficiently program using easy-to-understand entities that map directly to real-world business concepts (e.g. Customer) without concern for how the entity information is actually stored in a database (e.g. the multiple tables and relationships that store the customer data). Additionally, the EDM and EF enables DBA’s to continually optimize the data storage without disrupting applications that access this information since applications built using entities are shielded from underlying database changes.\u00a0Any updates to the database schema can be easily reflected in the entity mapping that binds applications to the databases.<\/p>\n

“Data Abstraction”, I get it but …<\/strong><\/p>\n

At this point, people usually\u00a0understand that entities efficiently abstract data access, but sometimes people don’t fully grasp the benefits. Studies suggest database applications consists of 20-40% data-access code. If that’s true, applying the low end projection on an application with 100,000 lines of code would result in 20,000 lines of data access code. That’s a lot of code to keep synchronized with a database. Extend this projection over several big applications that access the same databases, and multiply this over several departments in an organization, and the magnitude of the development and communication challenges becomes clear. Traditionally, database applications would access databases directly, so as the DBA’s maintain and evolve the database (e.g. table splitting, column changes, etc.), application code would need to be carefully updated and edited to support the changes. Search and replace is not enough to update the data-access code and mistakes can easily happen — some portions of code get updated, others don’t which could leave applications unstable and could ultimately result in data corruption. The devil is in updating countless access points of the same database object in the application code.<\/p>\n

Using the EDM and EF shields applications from having to reference database objects directly in code by centralizing the application\/database mapping in one place. If all applications use the same Entities, then updates to the underlying mapping of the entity to the database can be easily maintained and reflected across all applications. The EDM and EF allows databases to evolve independently from applications, without triggering an avalanche of application code changes. The EDM and EF acts as a powerful buffer\u00a0between the two worlds – protecting investments and logic in application code while allowing DBAs to evolve databases to meet the needs of an organization. Microsoft is very excited about the EDM and EF and believes that these free technologies will be instrumental in helping people build better applications, more efficiently.<\/p>\n

Good resources<\/strong><\/p>\n