Demystifying The Code » Entity Framework

Entity Framework Modeling: Select Stored Procedures

RobBagby — Fri, 13 Mar 2009 21:31:00 +0000

In my last post, I illustrated how to map action stored procedures (insert, update, delete) to entities. In this post, I will illustrate how you can import select stored procedures and map the results to entities.

Entity Framework Modeling: Action Stored Procedures

RobBagby — Fri, 13 Mar 2009 03:29:00 +0000

One of the biggest concerns I hear when discussing the Entity Framework is that of security. People are initially impressed and excited about the ease of developing a conceptual layer. Thanks to the magic of the Entity Framework and object services, you have an object layer that you can interact with that is mapped to your database. The excitement, however, wears off when people figure out that the default behavior for the action queries (insert, update and delete), along with selects is to generate dynamic SQL. In my humble opinion, this is a viable concern. In this post, I will discuss the security concerns with this default behavior and illustrate how you can map stored procedures to the actions.

Entity Framework Modeling: Table Per Hierarchy Inheritance

RobBagby — Thu, 12 Mar 2009 00:56:00 +0000

In a previous post, I illustrated how you can implement table-per-type inheritance in your model. You use table-per-type if your data model splits information for different logical things between tables that have 1:1 relationships. Some data models store multiple logical things in one table and use a discriminator column to advertise what kind of thing it is (please excuse the use of the word ‘thing’ – all of the good words like entity and type have alternate meanings that could cause confusion). With data models such as these, you can implement table-per-hierarchy inheritance. With table-per-hierarchy, you can model the same type of inheritance between entities as in table-per-type. The difference is that all of the entities are sourced from a single table, with the discriminator column being used as the differentiator.

Entity Framework Modeling: Entity Splitting Part II (adding inheritance)

RobBagby — Tue, 10 Mar 2009 20:09:00 +0000

In Entity Splitting Part I, I illustrated how you could map multiple tables to a single entity. In the post previous to that, I illustrated how you could build a completely different conceptual layer for the same model by implementing table-per-type inheritance. These are 2 completely different modeling scenarios. Entity Splitting results in a much simpler model, while table-per-type results in a more flexible model where you are able to cast between types and take full advantage of all of the benefits of inheritance. In this post, I want to illustrate that this is not necessarily an either-or decision. You can mix and match if it meets the need of your application.

Entity Framework Modeling : Entity Splitting

RobBagby — Mon, 09 Mar 2009 22:29:00 +0000

Entity Splitting involves mapping a single entity in the conceptual layer to multiple tables in the store. To put that into English, suppose that you have a normalized data structure. Within this structure, you have a table that stores “People” and additional tables that store information about specific kinds of people like “Students”, “Business Students”, “Instructors” and “Admins” (see below). In this post, I will illustrate how to implement Entity Splitting in the Entity Framework.

Entity Framework Series Index

RobBagby — Sat, 07 Mar 2009 05:55:00 +0000

I am in the process of doing a brief series of blog posts and screencasts on the ADO.NET Entity Framework. This page will serve as an index. I will keep it up to date.

Entity Framework Modeling: Table Per Type Inheritance

RobBagby — Fri, 06 Mar 2009 21:44:00 +0000

One of the beauties of the Entity Framework is that we are able to model rich conceptual layers that meet the needs of our applications. Another way of putting this is that we are able to create application-centric views of our data stores. This conceptual layer may look similar or drastically different from how the underlying data is stored. Further, we can add in application concepts such as inheritance. A table-per-type model is a way to model inheritance where each entity is mapped to a distinct table in the store. Each table contains all of the properties for the entity, as well as a key that maps ultimately to the root table / entity.