The beginning of a software project can be a great time to look at your tools with fresh eyes. Sure, you’ve been doing just fine all along with Visual Studio 2005 for years, but all right, fine now that 2010 is in beta it’s probably time to take a hard look at Visual Studio 2008.

Let me tell you, I feel as though I have awoken from a deep sleep. I’ve had my head down managing projects and launching programs for so long that I feel like a decade or more has passed. You have to keep in mind, I wrote a lot of code that looked like this:

SqlCommand scGetResults = new SqlCommand();
scGetReults.Connection = dbConn;
scGetResults.CommandType = System.Data.CommandType.StoredProcedure;
scGetResults.Parameters.AddWithValue("@programid", argProgrmId);
DataReader drResutls = scGetResults.ExecuteReader();
if (drResults.HasRows() ) {
     while ( drResults.Read() ) {
          // do something
     }
}

And really, this doesn’t look a lot different from the PHP I was writing five years ago, with the exception of parameters:

mysql_connect("localhost", "mysql_user", "mysql_password") or
die("Could not connect: " . mysql_error());
mysql_select_db("mydb");
$result = mysql_query("SELECT id, name FROM mytable");
while ($row = mysql_fetch_array($result, MYSQL_NUM)) {
 printf("ID: %s  Name: %s", $row[0], $row[1]);
}
 

So to go to StackOverFlow DevDays in October and see a live coding demo using LINQ I was blown away! I mean how much cooler is that?

var myList = (
     from c in _db.CustomerSet
     where c.Account.Balance > minAccountBal && c.Program.OwnerId == i
     select c).ToList();

Upon further inspection, LINQ can’t be used everywhere – our app requires access to hundreds of databases (scaling to thousands) using stored procedures; and, well, Entity Framework does not support stored procedures very nicely yet. LINQ-to-SQL does, but Microsoft has made noises that seem to indicate it won’t be supported in future.

I have heard they’re fixing that in .NET 4.0, which ships with VS2010… something tells me I won’t be holding my breath for its release. I am loving ASP.NET/MVC however!

Listed below are some issues and solution you may come across when trying access a LINQ to Entity layer from a WCF Service located in a separate project.

Problem:
Argument Exception: “The specified named connection is either not found in the configuration, not intended to be used with the EntityClient Provider, not valid.”

Solution:

The class library which contains the EDMX file contains an app.config file with the entity connection string. When access this from the WCF layer, there is no reference to it unless you include it in the web.config of the WCF layer

To fix the problem, copy the connection string from the app.config to the ConnectionStrings section of the web.config of the WCF project.

However, on doing this, you may receive another exception message:

MetadataException: Unable to load the specified metadata resource.

to

Todos los que nos dedicamos al desarrollo de software sabemos que siempre hay una tarea inevitable. Me estoy refiriendo a la grabación y recuperación de datos en una base de datos relacional. Pero si además nuestra aplicación es de cierta complejidad, con un modelo de dominio y entidades de negocio, la cosa se complica.  No basta con recuperar los datos, además hay que “convertirlos” de alguna forma en nuestras entidades de negocio. Para grabarlos hay que hacer lo contrario: “convertir” nuestras entidades en datos grabables con una consulta SQL. Para llevar a cabo estas tareas en .NET hay varias opciones:

• Mediante un DataReader transferir manualmente los valores de las filas a las propiedades de las entidades.
• Usar un DataCommand para insertar o actualizar datos, pasándole los valores de las propiedades de una entidad.
• Usar DataSets tipados como entidades.
• Leer un DataTable para transferir los valores de sus columnas a las entidades y viceversa.
• Usar una herramienta ORM (Object-Relational Mapping) como NHibernate, para asociar nuestras entidades a tablas y sus propiedades a valores de columnas.

Vamos a centrarnos en este post en la última opción y cómo se puede llevar a cabo usando Entity Framework (EF).

EF es, como su nombre indica, un framework que nos permite mapear manualmente asociaciones entre entidades de negocio y una base de datos. De hecho, nos permite generar un modelo de dominio con estas entidades a partir de una base se datos. En la práctica lo más frecuente es hacer lo opuesto: a partir de un modelo de dominio generar un modelo de datos, pero la versión de EF incluida con la versión 3.5 del Framework  no lo permite. En cualquier caso, siempre es posible modificar posteriormente el modelo de dominio, agregar relaciones de herencia, partir entidades, etc… y mantenerlo sincronizado con la base de datos.

Primeros pasos con EF

Lo primero que hay que hacer, si no lo hemos hecho ya, es instalar el SP1 de Visual Studio 2008. De lo contrario no podremos usar algunas plantillas y librerías que necesitaremos. Seguidamente tendremos que tener la base de datos (o parte de ella) ya creada.

Vamos a partir de un ejemplo sencillo y bastante común: una base de datos que contiene pedidos. Por simplificar vamos a tener solamente tres tablas con un número reducido de campos, donde las claves primarias son autonuméricos:

Base de datos original

Crear un modelo de dominio

Personalmente prefiero crear el modelo de dominio en un proyecto de librería de clases separado, de modo que eso haremos. Posteriormente agregamos a nuestro proyecto un nuevo elemento ADO.NET Entity DataModel:

Agregando un nuevo Entity Data Model

Los siguientes pasos son indicar que queremos generar el modelo a partir de una base de datos  y posteriormente indicar la conexión a esa base de datos. Hay que tener en cuenta que como  resultado se creará un fichero de configuración con la cadena de conexión correspondiente.

Generando un modelo desde una base de datos

Seleccionando la conexión

El último paso consiste en seleccionar las tablas a partir de las cuales se generarán las entidades. También hay que definir el espacio de nombre donde se definirán estas entidades generadas (en nuestro caso Acme.Model). Es posible hacer el mapeo a vistas y procedimientos almacenados, pero eso es un tema para otro post.

Seleccionando las tablas

Una vez hecho esto se habrá añadido a nuestro proyecto un fichero con extensión .edmx. No vamos a entrar en detalles sobre su contenido, por ahora basta  con saber que en él se implementan una serie de clases parciales, una por cada tabla. Estas clases son las entidades de negocio y se pueden ampliar para incluir nuestros métodos de negocio, simplemente añadiendo al proyecto otra clase parcial con el mismo nombre. También se definen los mapeos entre los campos de la base de datos y las propiedades de las entidades.

Por defecto el modelo creado tiene entidades con los mismos nombres que las tablas. Las propiedades tienen también los mismos nombres que las columnas de las tablas. Es aconsenjable cambiar estos nombres si se considera que pueden inducir a confusión. En nuestro caso hemos renombrado las entidades en singular.

Modelo generado

También se puede ver que hay relaciones entre las entidades. Corresponden a restricciones FK de la base de datos, aunque en el modelo EF se transforman en propiedades de navegación. Por ejemplo, la entidad Order tiene una propiedad Details para obtener todos sus detalles asociados. La entidad Detail tiene una propiedad Order que permite acceder a datos del pedido.

Y la pregunta obvia es: ¿qué se puede hacer con este modelo que hemos generado?. Por lo pronto diremos que todo el código de lectura y escritura en la base de datos subyacente y su paso al modelo de objetos ya no tendremos que escribirlo. No hace falta decir la cantidad de tiempo y esfuerzo que ahorra esto. Tampoco tendremos que preocuparnos de abrir y cerrar conexiones o de transacciones, EF se encarga de ello por nosotros. El siguiente punto es ver cómo se usa este modelo en una aplicación.

Usar el modelo de dominio

Todo gira en torno a un objeto que se generó en el paso anterior y que contiene todas las otras entidades. Este objeto contenedor hereda de System.Data.Objects.ObjectContext y su nombre lo hemos definido al principio, cuando elegimos la conexión a la base de datos (en nuestro caso es OrderContext). No obstante, este nombre y también el de su espacio de nombres se puede cambiar editando el fichero fuente del diseñador del modelo de datos (en nuestro caso, Orders.Designer.cs).

Para probar el modelo recién generado hemos añadido a la solución una aplicación de consola, a la cual le añadimos una referencia al proyecto anterior y además una referencia al ensamblado System.Data.Entity, de lo contrario no se podría compilar. También es necesario agregar un fichero de configuración a esta nueva aplicación e incluir en él la cadena de conexión a la base de datos.

Insertar nuevos datos

La inserción en tablas raíz se hace a través de los métodos de OrderContext (los cuales, recordemos, son generados automáticamente). Tenemos tres entidades en nuestro modelo y tenemos tres métodos AddToOrders(), AddToDetails() y AddToProducts(). Por ejemplo, veamos cómo se insertarían dos nuevos productos:

 static void Main(string[] args)
 {
 // Referencia al contenedor
 OrderContext context = new OrderContext();
 // Paso 1: Insertar productos
 // Inserta un producto
 Product product = new Product()
 {
 Name = "Laser Sabre",
 Description = "Original Star Wars Laser Sabre, available in three colors",
 Price = 350.90
 };
 context.AddToProducts(product);
 // Inserta otro producto
 Product anotherProduct = new Product()
 {
 Name = "Darth Vader's Mask",
 Description = "A excellent replica of the Dark Lord's Mask and helmet",
 Price = 650.90
 };
 context.AddToProducts(anotherProduct);
 context.SaveChanges();

Cuando se invoca al método SaveChanges() se llevan a cabo TODOS los cambios dentro de una transacción. En este caso se insertarían ambos productos. Posteriormente estos datos se podrían recuperar a través de la colección Products, también generada de forma automática.

// Paso 2: obtener la lista de productos
 foreach (Product p in context.Products)
 {
 Console.WriteLine(p.Name + " - " + p.Description);
 }

Grabar datos en tablas relacionadas

En nuestro ejemplo tenemos una entidad Order con datos de pedidos, la cual a su vez tiene una propiedad Details que contiene una colección de detalles de pedido. Veamos cómo se grabaría un pedido con dos detalles, uno correspondiente a cada producto:

// Paso 3: crear un pedido con ambos productos
 Order order = new Order();
 foreach (Product p in context.Products)
 {
 Detail det = new Detail();
 det.Product = p;
 det.Price = p.Price;
 det.Quantity = 1;
 order.Amount = order.Amount + det.Quantity * det.Price;
 order.Details.Add(det);
 }
 order.VAT = 16;
 order.Total = order.Amount + order.Amount * (order.VAT / 100);
 context.AddToOrders(order);
 context.SaveChanges();

Al principio creamos un nuevo pedido y en el bucle foreach recorremos los productos y por cada uno creamos un detalle, los cuales insertamos en Order.Details. Al final grabamos todos los cambios con una llamada a SaveChanges(). Vale la pena mencionar que, a nivel de base de datos, los valores de la clave en DETAILS han sido establecidos automáticamente por EF a partir de los de las claves externas.

Recuperar datos de tablas relacionadas

Es muy fácil recuperar todos los datos relacionados de un pedido, aunque algunos puntos no son tan obvios. Veamos el código:

// Paso 4: recuperar el pedido y datos asociados de la base de datos y actualizarlo
 order = (from ord in context.Orders
 where ord.Id == 1
 select ord).First();
 if (!order.Details.IsLoaded)
 order.Details.Load();
 foreach (Detail det in order.Details)
 {
 det.Quantity = det.Quantity + 1;
 order.Amount = order.Amount + det.Price;
 }
 order.Total = order.Amount + order.Amount * (order.VAT / 100);
 context.SaveChanges();

La primera consulta LINQ obtiene el pedido cuyo número es 1. El problema es que no devuelve un pedido, sino una colección con un único pedido. Por ello aplicamos el operador First().

Por otra parte, los detalles del pedido no se cargan automáticamente. La propiedad order.Details.IsLoaded nos indica si se ha cargado o no ( y por tanto, en un primer momento tiene valor false). Para cargar los detalles del pedido invocamos al método order.Details.Load().

Finalmente, tras actualizar todos los datos grabamos todo de golpe mediante una llamada a SaveChanges().

Borrar datos de tablas relacionadas

Finalmente veamos cómo borrar datos de tablas relacionadas, en este caso un pedido completo con sus detalles. Este método que veremos implica cargar primero el pedido con sus detalles para posteriormente borrarlo, lo cual no parece muy eficiente. Hay otra forma de borrar datos sin tener que cargarlos pero es un tema para otro post.

// Paso 5: borrar el pedido y los detalles
 order = (from ord in context.Orders
 where ord.Id == 1
 select ord).First();
 if (!order.Details.IsLoaded)
 order.Details.Load();
 order.Details.Clear();
 context.DeleteObject(order);
 context.SaveChanges();

En primer lugar seleccionamos el pedido y cargamos sus detalles. Mediante el método Clear() de order.Details los eliminamos del pedido (y posteriormente se eliminarán de la base de datos). Luego borramos el pedido mediante context.DeleteObject(). Lo que realmente ocurre es que tanto el pedido como los detalles se marcan para borrar, lo cual se lleva a cabo finalmente en la llamada a context.SaveChanges().

Conclusiones rápidas

Mediante Entity Framework hemos creado en segundos un pequeño modelo de dominio plenamente operativo, cuyo desarrollo manual nos habría llevado bastante más tiempo. Por supuesto, se trataba de un caso sencillo y no hemos visto características avanzadas como herencia o partición de entidades. Tampoco hemos visto cómo enlazar entidades a procedimientos almacenados, algo que en aplicaciones de gestión reales tendríamos que hacer casi con toda seguridad. Pero estas son otras historias y deben ser contadas en otra ocasión.

در اکثر برنامه های کامپیوتری نیاز به ذخیره و بازیابی داده ها وجود دارد. داده هایی که بدون آن ها سیستم نرم افزاری ما معنایی ندارد. برنامه نویسان معمولاً راه های مختلفی برای این کار سراغ دارند. کسانی که با دات نت فریم ورک برنامه نویسی می کنند راه های مختلفی برای دسترسی به داده ها دارند. در این مطلب با تکنولوژی های مایکروسافت برای این کار آشنا خواهیم شد و سه ORM معروف دنیای دات نت را معرفی خواهیم کرد. مایکروسافت انتخاب های زیادی برای دسترسی به داده ها به برنامه نویسان دات نت می دهد که شما باید با بررسی آن ها و با توجه به نیازهای خودتان یکی از آن ها را انتخاب کنید.

ADO.NET

ADO.NET مجموعه ای از کامپوننت هاست که برنامه نویسان می توانند از آن ها برای برقراری ارتباط با دیتابیس های مختلف استفاده کنند. ADO.NET بخشی از کتابخانه کلاس های پایه دات نت فریم ورک است که توسط مایکروسافت توسعه داده می شود. برنامه نویسان به صورت گسترده از این تکنولوژی برای دسترسی و دستکاری داده های ذخیره شده در یک دیتابیس رابطه ای استفاده می کنند. ADO.NET می تواند با اکثر دیتابیس های موجود کار کند، هر چند به صورت پیش فرض در دات نت فریم ورک فقط فراهم کننده های SQL Server، OleDb و Odbc وجود دارد، افراد و شرکت های دیگر فراهم کننده های دیتابیس های دیگر را برای دات نت ایجاد کرده اند.

برای هر Provider کامپوننت هایی وجود دارند که برنامه نویس با استفاده از آن ها به مقصودش می رسد. به طور مثال برای استفاده از SQL Server در روش ADO.NET کامپوننت هایی مانند SQLConnection و SQLCommand وجود دارد که با استفاده از آن ها می توانید یک دستور SQL را روی داده های موجود در یک دیتابیس SQL Server اجرا کنید. با SQLConnection به دیتابیس موجود در SQL Server وصل می شویم و با استفاده از یک SQLCommand می توانیم یک عبارت T-SQL را که می تواند دستور INSERT, UPDATE, DELETE یا SELECT باشد یا حتی یک Stored Procedure یا عبارت DDL باشد را برای مقصود خاصی روی دیتابیس اجرا کنیم. چون ADO.NET در مورد سینتاکس دیتابیس چیزی نمی داند، دستورات را به صورت یک رشته ساده به SQLCommand می دهیم و این شیء نیز به صورت مستقیم به دیتابیس دستور می دهد.

string query = "SELECT * FROM tblCustomers";
SqlConnection con = new SqlConnection(cnnString);
SqlCommand command = new SqlCommand(query, con);
con.Open();
SqlDataReader reader = command.ExecuteReader();
while (reader.Read())
{
Response.Write(reader.GetInt32(0) +
reader.GetString(1));
}

نکته ای که باید در مورد ADO.NET بدانید این است که برای استفاده از هر سیستم دیتابیس رابطه ای، مجموعه کامپوننت های جدایی وجود دارد. در مثال بالا از آبجکت های مربوط به SQL Server استفاده کردیم. اگر بخواهید مثلاً از یک دیتابیس اوراکل در برنامه خود استفاده کنید، بایستی از کامپوننت های مربوط به اوراکل استفاده کنید. خوشبختانه تمام این کامپوننت ها بر پایه یک Interface ساخته شده اند، این یعنی شما می توانید با استفاده از کلاس DbProviderFactory برنامه ای بسیازید که با چند نوع دیتابیس مختلف کار کند.

Linq to SQL

مایکروسافت با دات نت فریم ورک 3.0 و 3.5 یک ORM به نام Linq to SQL را به عنوان بخشی از پروژه LINQ خود عرضه کرد. این شرکت مدت ها پیش از آن قول داده بود که یک ORM برای دات نت فریم ورک طراحی کند اما تا نسخه 3.0 دات نت فریم ورک خبری از آن پروژه نشد. Linq to SQL به شما اجازه می دهد که کوئری های LINQ را روی دیتابیس های SQL Server اجرا کنید. علاوه بر این از یک Mapping Framework بهره می برد که به برنامه نویسان اجازه Map کردن جدول های یک دیتابیس را به کلاس ها و بالعکس می دهد. این کار در ویژوال استادیو می تواند به صورت ویژوال یا کدنویسی انجام گیرد. به این صورت که برای هر جدول از دیتابیس یک کلاس تعریف می شود که هر ستون از یک جدول به عنوان یک Property درون آن کلاس تعریف می شود.

نمایی از ابزار طراحی ویژوال Linq to SQL

به مثال زیر توجه کنید :
public class Customer
{
[Column(Name="CustomerID",IsPrimaryKey = true)]
public long ID
{
get { return _ID;}
set { _ID = value;}
}
[Column(Name = "CustomerName")]
public string Name
{
get { return _name; }
set { _name = value; }
}
}
کلاس بالا به جدول tblCustomers که دارای دو ستون CustomerID و CustomerName است Map می شود. قبل از اینکه بخواهید از Linq to SQL استفاده کنید باید این کلاس ها را تعریف کنید. ویژوال استادیو 2008 دارای ابزاری است که به صورت ویژوال به شما امکان Map کردن جدول های یک دیتابیس SQL Server را به کلاس های دات نت می دهد. این ابزار می تواند به صورت اتوماتیک کلاس های مورد نیاز شما را از روی مدل دیتابیس بسازد، و حتی اجازه تغییرات دستی و ایجاد Viewهای مختلف از دیتابیس را به شما می دهد. عملیات Mapping با استفاده از DataContext (که یک رشته اتصال به سرور نیاز دارد) پیاده سازی می شود. سپس شما قادر خواهید بود کوئری های LINQ خود را روی دیتابیس موجود در سرور اجرا کنید، که البته این کوئری ها ابتدا به دستوارت T-SQL متناظر ترجمه و سپس روی دیتابیس مورد نظر اجرا می شوند.

Entity Framework

Entity Framework یک فریم ورک ORM برای دات نت فریم ورک است که نسخه یک آن به همراه دات نت فریم ورک 3.5 سرویس پک 1 عرضه شد اما مورد استقبال توسعه دهندگان قرار نگرفت. نسخه 2 این فریم ورک به صورت بتا به عنوان بخشی از ویژوال استادیو 2010 قابل دسترس است. ADO.NET Entity Framework نام اصلی این فریم ورک است و جزئی از تکنولوژی ADO.NET است.

ابزار طراحی Entity Framework در ویژوال استادیو

Entity Framework مدل رابطه ای موجود در یک دیتابیس را به مدل مفهمومی تبدیل می کند و آن را به اپلیکیشن ما تحویل می دهد. در مدل رابطه ای عناصر ترکیبی از جداول هستند، به همراه کلید های اصلی و خارجی که جدول ها را به هم مرتبط می سازند. برعکس آن، انواع موجودیت ها مدل مفهومی داده را تعریف می کنند. انواع موجودیت  اجتماعی از چند فیلد است (هر فیلد به یک ستون از دیتابیس Map می شود) و می تواند شامل اطلاعات از چند جدول فیزیکی باشد. انواع موجودیت می توانند به هم مرتبط باشند، مستقل از ارتباطاتی که در مدل فیزیکی دارند. شمای منطقی و نگاشت (mapping) آن به شمای فیزیکی به عنوان یک Entity Data Model یا EDM نمایش داده می شوند که مشخصات EDM در یک فایل XML ذخیره می شود. Entity Framework از EDM برای انجام عملیات نگاشت و دادن قابلیت کار با موجودیت ها به اپلیکیشن استفاده می کند. Entity Framework اطلاعات مورد نیاز هر موجودیت را با Join کردن چندین جدول از مدل فیزیکی (دیتابیس) بدست می آورد. هنگامی که اطلاعات یک موجودیت آپدیت می شود، Entity Framework بررسی می کند که داده ها مربوط به کدام یک از جدول های موجود در دیتابیس هستند، سپس آن ها را با دستور SQL مناسب آپدیت می کند.

هر چند Entity Framework و Linq to SQL بسیار شبیه به هم به نظر می رسند، هر دو ابزارهایی برای طراحی گرافیکی و ویزاردی برای نگاشت یک دیتابیس به مدل شیء گرا دارند و هر دو می توانند از کوئری های LINQ برای مقصود خاصی استفاده کنند، اما با هم تفاوت هایی هم دارند. بیان تفاوت های این دو در این مطلب جایی ندارد.

NHibernate

نمی توان در مورد ORMها در دات نت صحبت کرد اما نام NHiernate را ذکر نکرد. NH یک فریم ورک ORM اوپن سورس برای دات نت فریم ورک است که از روی پروژه موفق Hibernate جاوا وارد دنیای دات نت شد. توضیحات بیشتر در مورد NHibernate توضیحات اضافی است، زیرا این فریم ورک هم وظیفه ORMهای دیگر را انجام می دهد. اکثر برنامه نویسانی که از NH برای نگاشت استفاده می کنند، ابتدا کلاس های خود را تعریف می کنند و سپس با استفاده از یک فایل XML آن ها را به جدول های دیتابیس Map می کنند. Linq to SQL و Entity Framework برخلاف NHibernate از روش Model-first یا مبتنی در دیتابیس استفاده می کنند، به این معنی که هر دو ORM تصور می کنند شما دیتابیسی در اختیار دارید که می خواهید آن به تعدادی آبجکت Map کنید.

در مورد Nhibernate بیش از این صحبت نمی کنم، آقای وحید نصیری در اینجا به صورت کامل در مورد این ORM محبوب نوشته است.

farasun.wordpress.com

انتخاب از میان روش های بالا به عهده خود شماست. در این مطلب کوتاه نمی توان به بررسی تمام زوایا و تفاوت های میان آن ها پرداخت. در مطالب آینده سعی میکنم در مورد نحوه استفاده از هر کدام یک مثال عملی بزنم (البته به جز NHibernate).

ASP.NET MVC is the new cool kid on the block of Microsoft platforms. I have been using it for a little over half an year and I can say that I like it much more than ASP.NET. Why is that?

1. No more viewstate which adds an additional overhead on your page
2. Clean separation of concerns through the MVC pattern
3. Going back to the basics (standard HTML controls) – most of the ASP.NET server controls do not work with ASP.NET MVC because there is no viewstate and the notion of postbacks

This would be the first of a series of blog posts that I would write about ASP.NET MVC and some performance techniques that could get the most out of it. We will start by building a simple application that uses Ext JS Grid to display employees data that is fetched from the AdventureWorks database. Since jQuery is being shipped with Visual Studio for over a year now I will be using it as well – as an adapter to Ext JS (I am a big fan of jQuery).

I am going to create my app using Visual Stidio 2010 Beta 2 which ships with ASP.NET MVC 2 Beta. If you are using Visual Studio 2008 you have to download the Beta and install it on your machine. First we start by creating a new ASP.NET MVC Project.

New ASP.NET MVC Project

Next I am copying the necessary files that are needed for Ext JS – ext-all.debug.js and ext-jquery-adapter.js to an extjs folder I created under my Scripts folder which was created for me by the ASP.NET MVC project template. I will use the latest version of the library – Ext JS 3.0.3.

In the next step we need to include the css and js files – I will put them in the master page (located under Views/Shared folder):

<link href="../../Content/resources/css/ext-all.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="../../Scripts/jquery-1.3.2.js"></script>
<script type="text/javascript" src="../../Scripts/extjs/ext-jquery-adapter.js"></script>
<script type="text/javascript" src="../../Scripts/extjs/ext-all-debug.js"></script>

The order in which you include the JavaScript files is important.

Note: Please remember that it is essential to put all your css files in the head section of the page – this improves the loading of your page. All js files that are needed for the page rendering should also be put in the head, otherwise they should be put at the end of your page. I will talk more about this in a future blog post.

For the purpose of this sample application I will use the AdventureWorks database alongside with the Entity Framework for my data model. First we have to add the database into the App_Data folder and then create our data model in the Models folder. The Entity Framework will generate all the necessary entities and a context class and we are ready to write our data access code – I will write my LINQ queries against the database in the controller classes though you will not do this in a real world application. You would use for example the Repository pattern, put your data access logic in a separate assembly, maybe write your own services that will abstract away the business logic and inject them with some Dependency Injection framework, etc.

Entity Framework Data Model

Now that we have everything in place we can write an action method which would return a subset of employees:

[AcceptVerbs(HttpVerbs.Get)]
[ActionName("Employees")]
public JsonResult GetEmployees()
{
   int start = Convert.ToInt32(Request.QueryString["start"]);
   int limit = Convert.ToInt32(Request.QueryString["limit"]);

   using (AdventureWorksEntities dbContext = new AdventureWorksEntities())
   {
      var query = dbContext.Employees
                              .Include("Contact")
                              .OrderBy(emp => emp.EmployeeID);
      var result = (from emp in query
                                  .Skip(start).Take(limit).ToList()
                    select new
                    {
                       ID = emp.EmployeeID,
                       FirstName = emp.Contact.FirstName,
                       LastName = emp.Contact.LastName,
                       BirthDate = emp.BirthDate.ToShortDateString(),
                       HireDate = emp.HireDate.ToShortDateString(),
                       VacationHours = emp.VacationHours,
                       SickLeaveHours = emp.SickLeaveHours,
                       Email = emp.Contact.EmailAddress,
                       Phone = emp.Contact.Phone
                    }).ToList();

      return Json(new { data = result, totalCount = query.Count() }, JsonRequestBehavior.AllowGet);
   }
}

Notice the AcceptVerbs attribute that the method is decorated with – it tells the framework that only GET requests are allowed to call the method through the HttpVerbs enumeration. This was the way to constrain the requests so far but in the new version of ASP.NET MVC there are some new handy attributes that you could use as well – HttpGet, HttpPost, HttpPut and HttpDelete which do the same thing. I am using the ActionName attribute to explicitly add a name for my action method so that I could have a nice URL schema for my actions and use the same name for different CRUD operations (I just need to use different verb for the requests).

In the method itself I create an instance of the database context and based on the parameters received from the grid I do paging with the LINQ extension methods Skip and Take. The interesting part is when the data is returned as a JSON – in ASP.NET MVC 1 the JSON method required a single parameter while now you have to pass an additional parameter of type JsonRequestBehavior. It is introduced for security reasons and you as a developer should explicitly decide whether or not to support GET requests. The problem is that if you return a response in the form of a JSON Array for a GET request it could be easily compromised, so it is suggested to wrap it inside a JSON object or do POSTs instead of that. You could read more about this in Phil Haack’s post.

Next we need to write the JavaScript code that will instantiate our grid and fetch the data from the server:

<script type="text/javascript">
   $(document).ready(function () {
      var store = new Ext.data.Store({
         proxy: new Ext.data.HttpProxy({
            url: 'Home/Employees',
            dataType: 'json',
            method: 'GET'
         }),
         reader: new Ext.data.JsonReader({
            root: 'data',
            totalProperty: 'totalCount'
         }, Ext.data.Record.create([
            { name: 'ID', mapping: 'ID' },
            { name: 'FirstName', mapping: 'FirstName' },
            { name: 'LastName', mapping: 'LastName' },
            { name: 'BirthDate', mapping: 'BirthDate' },
            { name: 'HireDate', mapping: 'HireDate' },
            { name: 'VacationHours', mapping: 'VacationHours' },
            { name: 'SickLeaveHours', mapping: 'SickLeaveHours' },
            { name: 'Email', mapping: 'Email' },
            { name: 'Phone', mapping: 'Phone' }
         ]))
      });

      var grid = new Ext.grid.GridPanel({
         store: store,
         columns: [
            { header: 'ID', dataIndex: 'ID', hidden: true },
            { header: 'First Name', dataIndex: 'FirstName', width: 100 },
            { header: 'Last Name', dataIndex: 'LastName', width: 100 },
            { header: 'Birth Date', dataIndex: 'BirthDate', width: 100 },
            { header: 'Hire Date', dataIndex: 'HireDate', width: 100 },
            { header: 'Vacation Hours', dataIndex: 'VacationHours', width: 100 },
            { header: 'Sick Leave Hours', dataIndex: 'SickLeaveHours', width: 100 },
            { header: 'Email', dataIndex: 'Email', width: 200 },
            { header: 'Phone', dataIndex: 'Phone', width: 200 }
         ],
         renderTo: 'grid',
         width: 1000,
         autoHeight: true,
         bbar: new Ext.PagingToolbar({
            store: store,
            pageSize: 25,
            displayInfo: true,
            displayMsg: 'Displaying employees {0} - {1} of {2}',
            emptyMsg: "No employees to display"
         }),
         pageSize: 20,
         title: 'Employees'
      });

      grid.getStore().load({ params: {
         start: 0,
         limit: 25
      }
   });
});
</script>

When the DOM is ready to be manipulated I create a Store which will make the request to the server and use a JsonReader object which has all the necessary mappings in place to parse the data. Then an instance of the Grid is created with the store that was created in the previous step and columns which are mapped to the parsed JSON result object. That’s all you need to do – create these objects passing some configurations and you are ready to get your data. All the tricky parts of making an XmlHttpRequest, parsing the JSON, creating the HTML for the grid is done for you. Here is how the grid looks like when the application is run:

Ext Js Grid

This is a simple application in which I wanted to show you how to use Ext JS Grid to present data in a nice tabular fashion using ASP.NET MVC and Entity Framework. Here you could download the code for this app (I have not included the AdventureWorks database in order to keep the file size small, but you could download it from here).

In my next blog post I will show you how to write ASP.NET MVC HTML extension methods to include CSS and JavaScript files in your pages and how to instantiate some jQuery UI plugin widgets.

Just Test – Nuff Said? Nah.

Big discussion about unit testing.  Views ranged from 100% coverage is necessary, to some code is not worth the trouble.  The 100% camp was hit with this rebuttal:

How is the coverage measured?
Is it just checking which code blocks ran during the test?
What about covering different code paths?

Everyone was in favor and there were some interesting insights including an example of “correctness by construction” in Haskell:

…”correctness by construction” (aka “making illegal states unrepresentable”).  This approach relies on a rich type-system (and, at a deeper level, an interesting fact technically known as the “Curry-Howard isomorphism”).  Ideally, when this can be achieved you can completely discharge the need for a lot of unit tests (replacing sort of probabilistic certainty with actual certainty).

Plenty of good links were sent and summarized:

This study found bug reductions of 40-90% with 15-25% coding time added.

Some recommend testability above clarity.

Guidelines on proper coding for testability (in Java).

Miscellany

I heard some talk about an A team being formed to take on a project. I’d like to see the problem these guys can’t solve.

Check out this interesting tool for translating a data model into a class model with proper naming and casing using either Entity Framework or Linq2SQL.

All in all, a quiet week as expected.

I hear that EF in .Net 4.0 will be a bit better.  An experienced developer says:

A lot of the biggest issues I’ve had with EF … have been addressed in one way or another in the v2 that comes out with .NET 4.  Self-tracking entities, POCO objects as entities, persistence ignorance, etc. etc.  I don’t know how much they’ve improved the designer.  The v2 looks much, much better.  Generally, if you don’t see moving to .NET 4 in the medium term as likely, I would look seriously into nHibernate, but if .NET 4 is realistic, I would seriously consider EF v2.

I watched a good bit of the PDC 2009 webcasts last night and found there are some interesting technologies coming out. I don’t think it comes as much of a surprise that Microsoft is cramming Azure and Silverlight down developer’s throats. There were also talks of IE 9 (don’t worry they are just starting development) and Visual Studio 2010. In my opinion Visual Studio 2010 is a game changer in development if they can get the performance up and memory requirements down. The top feature in, in my opinion, is the historical debugging capability in IntelliTrace, which allows a snapshot call stack to be taken in a different environment and then allows a developer to open that snapshot and step through the source code right on their desktop.

All that aside, there seems to be an increased focus on data this year and a multitude of code name and product name changes. I want to provide an overview of my understanding of the recent items that were discussed at PDC 2009 relating to data.

• Windows Azure Tables and Blobs are a way to store data in the cloud. When that wasn’t enough Microsoft moved to Azure SQL Data Services. This technology allowed users to store data in SQL tables and was extremely scalable. Apparently the public doesn’t care about scale because they want relational. So Microsoft has renamed the offering to SQL Azure. The primary differences are that now you can actually use SQL Server Management Studio to connect using the (Tabular Data Stream) TDS protocol and you can use relational queries.
• Oslo was a metadata framework for managing data and has now been boiled down to M and Quadrant and now falls under a larger umbrella of SQL Server Modeling Services. Honestly I can’t quite see the compelling argument for this yet unless you are a DSL (domain specific language) designer.
• Astoria was a REST based data access service. It was renamed to ADO.Net data services and recently changed to WCF data services. The new name change also introduced OData, which sounds like the new ADO.Net (yes, yet another data access technology).
• Dallas is a new data service from Microsoft intended to create a market place for data, the new commodity (I guess this is Microsoft’s answer to Apple’s iTunes and App Store). There are some public data sets available already for free. It seems the intention here is to enable innovation using data.
• Pivot from Microsoft labs was one of the more compelling things I saw. It is essentially a new Internet browser that has an extension for understanding another new data format called Collection XML (cxml). The viewer uses Silverlight and DeepZoom to visualize data.
• LINQ to SQL was a compelling technology that abstracted developer from writing T-SQL code by using an ORM (object-relational mapper). However, it seems tying this technology to SQL Server was not popular with the real world and Microsoft has been strongly advising against using it. In the 4.0 version of the .Net framework Microsoft placed this technology within the ADO.Net Entity Framework (EF) and calls it “Direct Mapping”. The EF also supports mapping at a more abstract level using an Entity Data Model (EDM) and a raw schema, should that be desired.

Avant de se lancer dans des développements un peu trop compliqué, je voudrais savoir un peu comment marche la chose, au moins dans ses grandes lignes, et comment je vais pouvoir en tirer parti.

Entity Framework

Le modele edmx ( il va falloir que je me renseigne sur les termes avant la fin, moi…) me génère mes objets tout seul. ca j’apprécie beaucoup. je me retrouve donc avec un objet comme suit ( en fait c’est beaucoup plus long, mais j’ai décidé de me retreindre à l’essentiel) :

[EdmEntityTypeAttribute(NamespaceName="Localisation", Name="Culture")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class Culture : EntityObject
{
    public global::System.Int32 Id {get; set;}
    public global::System.String Language {get; set;}
    public global::System.String Country {get; set;}
}

Pour l’instant, je ne regarderais pas plus avant ce qu’ il y a dedans.

Et je ne m’attarderais pas non plus sur toutes les fonctions possibles contenues le modele edmx, mais par contre je vais les utiliser dans un classe RepositoryCulture.

public class CultureRepository: ICultureRepository
   {

       LocalisationContainer container ;

       public CultureRepository(string connectionstring)
       {
           container = new LocalisationContainer(connectionstring);
       }

       // Query Methods
       public IQueryable<Culture> FindAllCulture()
       {
           return  container.T_Culture;
       }
       public Culture FindCulture(int CultureId)
       {
           var culture=  from c in FindAllCulture()
                          where c.Id == CultureId
                           select c;
           return culture.SingleOrDefault();
       }

       // Insert/Delete
       public void AddCulture(Culture c)
       {
           container.T_Culture.AddObject(c);
           container.SaveChanges();
       }
       public void DeleteCulture(Culture c)
       {
           container.T_Culture.DeleteObject(c);
           container.SaveChanges();
       }

       // Persistence
       public void Save()
       {
           container.SaveChanges();
       }
   }

Cette dernière va me permettre de manipuler mon edmx, de façon sereine. Mais cela veut donc dire que je vais utiliser une interface afin de me préserver d’un éventuel changement d’humeur de ma part ( je pourrais avoir envie d’essayer Nhibernate par exemple, plus tard…  grrr…)

public interface ICultureRepository
    {
    // Query Methods
    IQueryable<Culture> FindAllCulture();
    Culture FindCulture(int CultureId);

    // Insert/Delete
    void AddCulture(Culture c);
    void DeleteCulture(Culture c);
    // Persistence
    void Save();

    }

Je dispose donc maintenant d’une méthode conviviale pour jouer avec mes données de Culture. Passons au coté MVC…

MVC

l’acces aux donnés

De la même façon, que je suis parti sur un concept simple pour le coté Entity Framework, je ferais de même pour ma première approche de MVC.

La première chose que je veux faire, c’est de pouvoir accéder aux donnés facilement dans mon application MVC, je vais donc poursuivre le travail effectué plus avant, et généraliser ma façon d’accéder aux infos. Pour ce faire, je vais utilser un composant d’injection de dépendance / Inversion de Contrôle  nommé StructureMap

Je ne susi réellement pas un expert de ce genre de composé, j ai donc repiqué beaucoup d’idée a un tutorial MVC de microsoft. Mais voilà ce que j’ai pu en tirer pour mon cas présent.

dans mon application_start , j’ai rajouté

        BootStrapper.ConfigureStructureMap();

           ControllerBuilder.Current.SetControllerFactory(
               new StructureMapControllerFactory()
               );

Cela me permet d’initialiser le composant. la classe BootStrapper consiste en deux lignes :

public class BootStrapper
   {
       public static void ConfigureStructureMap()
       {
           StructureMapConfiguration.AddRegistry(new DBServiceRegistry()); 
           StructureMapConfiguration.AddRegistry(new StorefrontRegistry());
       }
   }

Et la classe DBServiceReigistry, va me permettre d’instancier ma conenction à la bonne base pour entity :

public class DBServiceRegistry : Registry
    {
        public string ConnectionString
        {
            get
            {
                if (WebConfigurationManager.ConnectionStrings["Application"]==null)
                    throw new InvalidOperationException(“Conenction string Application cannot be null.”);
                if (string.IsNullOrEmpty(WebConfigurationManager.ConnectionStrings["Application"].ToString()))
                    throw new InvalidOperationException(“Connection string Application cannot be empty.”);

                return WebConfigurationManager.ConnectionStrings["Application"].ToString();
            }
        }

        protected override void configure()
        {

            ForRequestedType<System.Data.EntityClient.EntityConnection>()
                .TheDefaultIs(() => new System.Data.EntityClient.EntityConnection(ConnectionString))
                .CacheBy(InstanceScope.Hybrid);

        }
    }

tandis que StoreFrontRegistryx lui cataloguera, les différents repository que je peux avoir et instanciera la bonne classe.

public class StorefrontRegistry : Registry
    {
        protected override void configure()
        {

            #region repository
            ForRequestedType<ICultureRepository>()
              .TheDefaultIsConcreteType<CultureRepository>();

            ForRequestedType<ILocalisationRepository>()
              .TheDefaultIsConcreteType<LocalisationRepository>();
            #endregion
        }
    }

Pour l’instant, j’utilise une autre classe StructureMapControllerFactory, mais je n’ai pas encore pris le temps de changer quelque chose à l’intérieur, le besoin ne s’en est pas fait sentir tout du moins.

les routes

Pour mes routes je ne me suis pas trop embêté pour l’instant, et j ‘ai tapé dans le simple et efficace. J’ai codé en dur Localisation/Culture afin de faire un différence significative avec ce qui pourrait arrivé ensuite :

public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute(“{resource}.axd/{*pathInfo}”);

            routes.MapRoute(
                “home”,                                                  // Route name
                “home/{controller}/{action}/{id}”,                       // URL with parameters
                new { controller = “Home”, action = “Index”, id = “” }   // Parameter defaults
            );

            routes.MapRoute(
               “localisation”,                                              // Route name
               “localisation/culture/{action}/{id}”,                        // URL with parameters
                new { controller = “Culture”, action = “Index”, id = “” }   // Parameter defaults
           );

        }

Par ailleurs avant d’aller plus loin , j ai installé un autre composant RouteDebug.dll qui me permet de debugger mes routes, je pense que tôt ou tard, j’en aurais besoin.

Pour ce faire, j’ai rajouter mais commenté pour le moment l’instruction suivante :

          // ROUTES
           RegisterRoutes(RouteTable.Routes);
           //uncomment this line for route debugging
           //RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);

On peut voir dans ma route que j’instancie :

       new { controller = “Culture”, action = “Index”, id = “” } 

Ce faisant, j’instancie un contrôle nommé Culture.

le controller

Rien de plus simple que ce controller. Mais tout d’abord, faire attention à son vrai nom CultureController. C’est important afin que MVC ne se mélange pas les pinceaux.

Ensuite détaillons le controller :

son constructeur :

#region constructor

       public CultureController(ICultureRepository repository)
       {
           _repository = repository;
           if (_repository == null)
               throw new Exception(“Repository cannot be null”);
       }

       #endregion

Il prend en entrée un ICultureRepository  qui sera instancié par StructureMap avec la bonne classe.

et ensuite correspondant à l’ {action} de ma route :

      // GET: /Localisation/Culture/Index ou /Localisation/Culture
        public ActionResult Index()
        {
            IQueryable<Culture> cultures = _repository.FindAllCulture();
            return View(“Index”, cultures);
        }

Suivant l’url /Localisation/Culture/Index ou /Localisation/Culture, j’appellerais le Controller Culture et j’effectuerais l’action Index, qui me renverra la vue Index.

La vue Index prend en parametre un IQueryable<Cultures>, que je vais chercher au moment ou j’en ai besoin.

Cela fonctionne de la même facon pour les autres actions, avec un petit détail à voir, à savoir la méthode utilisé pour appeler l’url qui permettra sur la même Url De procéder à plusieurs actions différentes :

public ActionResult Details(int id)
public ActionResult Create()

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection collection)

[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Edit(int id)

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(int id, FormCollection collection)

[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Delete(int id)

Sur ce , il n’ y a plus qu’à créer les vues correspondantes

les Views

Personnellement, et pour le début, je ne me suis pas embêté, et j’ai pris l’assistant de visual studio pour les créer.  J’ai donc créé un répertoire Culture dans Views. Ceci est aussi important pour MVC.

Je pense qu il doit y avoir un moyen de changer ce paramètre par défaut , mais ce sera l’occasion de plus amples investigations.

Voilà ,c’est tout pour aujourd’hui. Bon c’est bien évidemment hyper débutant comme approche, mais c’Est ce que je suis, et je me disais que d’autres pourraient être intéressé par mon cheminement personnel, si jamais il y avait des amateurs de MVC et d’entity framework dans les parages!

La suite la semaine prochaine,

L’objectif que je me fixe dans les jours qui viennent est de réaliser une petite application de localisation en ASP.net et MVC. Il s’agit pour moi surtout de me familiariser avec ces techniques, et peut être que je pourrais vous emmener avec moi sur un petit bout de chemin, qui sait?

Tout d’abord le but, je vais m’exprimer avec les mots que je connais a savoir ceux de l’univers webform: Avoir une librairie de contrôle qui accepteront un clé (localisationKey) et un langage. Cette clé possède une date de départ et une date de fin. Et associé à cette clé, je veux avoir un article (LocalisationItem) qui lui contiendra le texte a afficher en fonction du langage. Cela permettra de pouvoir aficher un texte en plusieurs langues et qui pourra changer aussi en fonction de la date.

Bref, rien de bien compliqué, surtout que j’ai déjà fait tout ca en webform. Il s’agit aussi pour moi, de voir l’effort à fournir pour transoposer vers le support MVC.net du travail déjà fait en webform.

Dernière petite précision, l’intérêt va être aussi d’utiliser Entity framework de façon à générer ma base de données à partir du modèle.

Les outils à ma disposition :

• Visual Studio 2010
• Visual Studio 2005 expresse édition

Tout d’abord mon premier schéma de données :

Comme vous pouvez le constater, je pars du principe que je vais avoir des groupes qui contiendront des  groupes enfants, ou et des clés.

Et à chacune de ces clés, j’associe un item.

Lors de la création de mon schéma j’ai pris soin de spécifier pour chacun des id , la propriété StoreGeneratedPAttern=Identity. Cela me permet d’avoir un champ auto incrémenté du coté de ma base de données.

Du coté de ma solution, je m’oriente vers différents projets :

• site MVC
• Data
• Services
• Test

Tout ce ci n’est évidemment qu’une première approche, au fur et á mesure de l’avancée du projet j’affinerais un peu tout ca.

Voici le projet utilisé actuellement : solution VS 2010

Suite dans l’étape 2…

I was doing a lot of Linq2SQL recently and it was easy and convenient – I’d highly recommend it. Except for the fact that its now obsolete. Linq2SQL is being tossed aside in favor of Entity Framework, which is not as lightweight or simple . I would look into NHibernate from what I’ve read of Entity Framework.

In another version or two Entity Framework may get more of Linq2SQL’s simplicity and ease of use. Oh joy.

I recently answered a question on StackOverflow regarding partial commits. The poster was refering to two contexts being used to isolate changes from the ones he / she actually wanted to commit. I disagree with using two contexts when the same can be achieved with one. Below is a simple example of reverting all objects of a certain type to their original state, if you were to call a SaveChanges() on the context after this – only the remaining objects in added or changed state will commit – a partial commit. Very similar to another post I’ve pressed before – but hey… someone may search for this one

foreach (System.Data.Objects.ObjectStateEntry x in
MyEntity.ObjectStateManager.GetObjectStateEntries(EntityState.Added))
// or modified for that matter.
{
   if (x.EntityKey != null)
   {  
      if (x.Entity is MyClass)
      // look haven't tested this code, merely example and may have typo's
      {
         MyClass tmpObject = (MyClass)x.Entity;
         MyEntity.Refresh(RefreshMode.StoreWins, x);
      }
   }
}

There is a lot of control available to you if you track the items you’re wanting to “partial” commit. The ones you’re wanting to revert to original state or discard can be reverted or even removed completely from the context.

As I looked into the ITypedList interface I realized that perhaps everything I needed was already implemented as my business objects are generated by Linq-To-Sql? The answer turns out to be “sort-of”.

I’m taking a peek at both the Entity Framework and LINQ to SQL, and while I like the systems (and of course the LINQ integration) I’m a little skeptical on the data-binding aspect. I’ve taken query results and inspected them, and they don’t appear to implement the standard .NET list-binding interfaces (IBindingList, and more importantly ITypedList), leading me to believe that binding them to a grid (or anything else) is going to use reflection to get/set my entity properties. This seems like a comparatively expensive operation, especially when all of the code is generated anyway and could implement the interfaces.

via Does Entity Framework/LINQ to SQL Data Binding use reflection? – Stack Overflow.

Scenario: Important meeting! Too much coffee! Bad lighting! In walks the killer! Wait…

No, that’s wrong. In walks Visual Studio 2010 Beta 2 with an inability to open an EDMX created with Visual Studio 2010 Beta 1, asking if I’d like to open the file in an XML editor. Ack! A previously printed paper diagram (for the meeting) and a bit of time later I resolved the differences between my EDMX and a test EDMX created with Beta 2.

1. The Schema tag,next item after <edmx:StorageModels>, had the correct xmlns property but was missing entirely the xmlns:store property. Adding xmlns:store=”http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator” was required.
2. The Schema tag,next item after <edmx:ConceptualModels>, had the correct xmlns property but was missing entirely the xmlns:annotation property. Adding xmlns:annotation=”http://schemas.microsoft.com/ado/2009/02/edm/annotation” was required.
3. Changing all “store:” prefixed properties of elements within  ConceptualModels to be “annotation:” prefixed.
4. Swore at Microsoft a little for giving me the “prividledge” of hand-editing a 2400 line xml file.

A save and compile later I could open my diagram and proceed. Hope that helps!

I have been trying to practice domain driven design for the last few years.
During this time, I have learnt that there are almost as many ways to implement DDD as there are practitioners.

After studying a lot of different implementations I have seen two distinct patterns.

I call the first pattern “Aggregate Graph”:

When applying aggregate graphs, you allow members of one aggregate to have direct associations to another aggregate.
For example, an “Order” entity which is part of a “Order aggregate” might have a “Customer” property which leads directly to a “Customer” entity that is part of a “Customer aggregate”.

According to Evans book this is completely legal, any member of an aggregate may point to the root of any other aggregate.
Evans is very clear on the matter that aggregate root identities are global while identity of non root entities are local to the aggregate itself.

The opposite pattern would be what I call “Aggregate Documents”:

Here the aggregates never relate _directly_ to other aggregate roots.
Instead, the associations may be designed as “snapshots” where you store light weight value object clones of the related aggregate roots.
An “Order” entity would have a “Customer” property which leads to a “CustomerSnapshot” value object instead of a Customer entity.
This way each aggregate instance becomes more of a free-floating document.

Since I have been applying both of these patterns, I will try to highlight the pros and cons of them in the rest of this post.

Aggregate Graph

The Aggregate Graph pattern is the approach I used when I first started doing DDD and I think that it is the most common way to implement DDD.
Since I was an O/RM developer (NPersist) this felt very natural to me, I could design my object graph in our design tool and then draw a few boxes on top of it and claim that those were my aggregates.
I most often used eager load inside the aggregates and lazy load between aggregates in order to avoid that the entire database was fetches when one aggregate instance was loaded.

This had a very nice “OOP” feel to it, I was working with objects and associations and I could ignore that there even was a database involved.

My “Repositories” were mere windows into my object graph, I could ask a repository to give me one or more aggregate roots and from those object I could pretty much navigate to any other object in the graph due to the spider web nature of the aggregate graph.

The pros of this approach is that it is easy to understand, you design your domain model just like any other class model.
It also works very well with O/R mappers, features like Lazy Load and Dirty Tracking makes it all work for you.

However, there are a few problems with this approach too.
Firstly, Lazy Load in O/R mappers is an implicit feature, there is no way for a developer to know at what point he will trigger a roundtrip to the database just by reading the code.
It always looks like you are traversing a fully loaded object graph while you are in fact not.
This often leads to severe performance problems if your development team don’t fully understand this.

I have seen reports over this kind domain models where the implicit nature of Lazy Load have caused some 700 round-trip to the database in a single web page.

This is what you get when you try to solve an explicit problem in an implicit way.

If you are going to use Lazy Load, make sure your team understands how it works and where you use it.

Another problem with this approach arise when you need to fill your entities with data from multiple sources.
Many of the applications I build nowadays relies on data from multiple sources, it could be a combination of services and internal databases.

When using Lazy Load to get related aggregates, there is no natural point where you can trigger calls to the other data sources and fill additional properties.
You will most likely have to hook into your O/R mapper in order to intercept a lazy load and call the services from there.
nowadays, I mostly use the second approach, Aggregate Documents.

Aggregate Document

Aggregate Document approach is much more explicit in its design.
For example, if you want to find the orders for a specific customer;
Instead of navigating the “Orders” collection of “Customer”, you will have to call a “FindOrdersByCustomer” query on the “OrderRepository”.

While I do agree that this looks less object oriented than the first approach, this allows developers to reason about the code in a different way.
They can see important design decisions and hopefully avoid pitfalls like ripple loading.

Another benefit is that since you only work with islands of data, you can now aggregate data from multiple sources much easier.
You can simply let your repositories aggregate the data into your entities.
(If you do it inside the actual repository or let the repository use some data access class that does it for it is up to you)

You don’t have to hook into any O/RM infrastructure since you no longer rely on lazy load between aggregates.

Personally I use eager load inside my aggregates, that is, I fetch “Order” and “Order Detail” together as a whole.
A side effect of this is that since I don’t use Lazy Load between aggregates and don’t use Lazy Load inside my aggregates, my need for O/R mapping frameworks drops.
I can apply this design without using a full-fledged O/R mapper framework.
I’m not saying that you should avoid O/R mapping, just that it is much easier to apply this pattern if you can’t use an O/R mapper for some reason.

This also makes it easier to expose your domain model in an SOA environment.
You can easily expose your entities or DTO versions of them in a service.

Lazy Load and services don’t play that well together.

Maybe it looks like I dislike the first approach, this is not the case, I may very well consider it in a smaller project where there is just one data source and where the development team is experienced with O/R mapping.
You can also create hybrids of the two approaches;
e.g. In Jimmy Nilsson’s book “Applying Domain Driven Design and Patterns” there are examples where an “Order” aggregate have a direct relation to the “Product” aggregate while the same “Order” aggregate uses snapshots instead of direct references to the “Customer” aggregate.

Snapshots also comes with the benefit of allowing you to store historical data.
The snapshot can for example store both the CustomerId and the name of the customer at the time the order was placed.

Thats all for now.

//Roger

Entity Framework association is a different concept to FKs in the database schema.  Supporting or not supporting the Schema FKs has been a topic for debate in the community until now. Faisal Mohamood (Program Manager of Entity Framework) believes in the following prons and cons of using FKs in a model (Ref 1):

Benefits of Foreign Keys

1. Keeps it simple (for the simple cases)  and allows you to deal with relationship like you deal with them in the database
2. Technically, you can update relationships without having both ends loaded/materialized. This is however in reality not always interesting since you will likely load both ends but this feature is definitely useful.

Disadvantages of Foreign Keys in the Model

1. It is a part of the impedance mismatch problem.
2. It doesn’t allow the concepts that you would expect from relationships in objects (easily getting from one end to the other) for instance.
3. Having foreign keys as well as object references for relationship navigation presents the problem of two different artifacts representing relationships – this introduces complexity and now you have to make sure that you keep these two in sync.

I think the biggest disadvantage of FKs (stated in number 2) is the conflict with the object model pattern.

However, it seems that Microsoft decided that both sides of this discussion have their valid points. So in Entity Framework .Net 4, Fks are supported and it is up to the software architects to make their decision to just use  independent associations (.Net 3.5 SP1) or add the FKs to the model.

The following code snippets form ADO.Net blog illustrate the implication of using Fks as part of the model (Ref 2). In our model there are two entities Product and Category, with the association one to many where each Product belongs to one Category.

First:  Using the independent association between Product and Category.

public void Create_new_Product_in_existing_Category_by_reference()
{
    using (var context = new Context())
    {
        //Create a new product and relate to an existing category
        Product p = new Product
        {
            ID = 1,
            Name = "Bovril",
            Category = context.Categories
                        .Single(c => c.Name == "Food")
        };
        // Note: no need to add the product, because relating
        // to an existing category does that automatically.
        // Also notice the use of the Single() query operator
        // this is new to EF in .NET 4.0 too.
        context.SaveChanges();
    }
}

Second: Using the Foreign Key.

using (var context = new Context())
{
    //Create a product and a relationship to a known category by ID
    Product p = new Product
    {
        ID = 1,
        Name = "Bovril",
        CategoryID = 13
    };
    //Add the product (and create the relationship by FK value)
    context.Products.AddObject(p);
    context.SaveChanges();
}

Further Reading:

• [MSDN] Defining and Managing Relationships (Entity Framework)
• Inheritance and Associations with Entity Framework Part 3

References:

1. [blogs.msdn.com/EFDesign]Foreign Keys in the Conceptual and Object Models
2. [blogs.msdn.com/EFDesign]Foreign Keys in the Entity Framework

Se me ha preguntado recientemente bajo qué criterios debía tomarse la decisión de usar EF o LINQ2SQL y haré aquí un resumen de los que considero debían tenerse en cuenta:

En primer lugar debo decir que tengo la impresión de que el proyecto Linq to Sql, a pesar de ser una consecuencia esperable en términos de niveles de abstracción, fue desarrollado como un mientras-lanzamos-EF. Eso no hace que haya sido una mala herramienta y, casi que por el contrario, ha opacado en algunos escenarios al mismo EF. Si analizamos un poco el estado del arte del desarrollo web, lenguajes y frameworks ligeros como Ruby on Rails han devenido adicionalmente en ORM’s ligeros y allí tenemos en L2S un claro ejemplo. Así las cosas, L2S está orientado al desarrollo rápido de aplicaciones conectadas a datos en arquitecturas web o de escritorio. Hace sumamente sencillo el acceso a datos en gran parte por la naturaleza misma de Linq y su similitud con el Sql.

Con Entity Framework sucede que está orientado a la construcción de aplicaciones corporativas en las que el nivel de abstracción del lenguaje de los desarrolladores sea un factor clave. Por ejemplo, permite el mapeo de una clase a diferentes tablas así como usar elementos propios de la programación orientada a objetos tales como la herencia y el polimorfismo. Esto no en todos los casos es una ventaja puesto que tiende a hacer más complejas las situaciones que representa y deriva en olvidar los objetos POCO que tan cómodos suelen resultarnos, aunque sobre esto se haya prometido que en la versión 4.0 del framework se permitirá la compatibilidad entre clases sencillas de un modelo de negocios y EF.

Dicho lo anterior, yo usaría estas listas de chequeo para determinar si uso el uno o el otro:

¿Cuándo EF?

• Cuando se trata de una aplicación que puede estar conectada a fuentes de datos de diferentes proveedores. Sobre esto EF lleva un poco la ventaja puesto que los proveedores de acceso a datos de terceros tardan menos en aparecer e incluso MS ofrece uno para Oracle. L2S está prácticamente destinado a trabajar con SQL Server.
• Cuando se necesita un lenguaje de abstracción más cercano a la lógica de negocio. El nivel de abstracción de EF así como su capa de Object Services es mucho más amplia y está orientada a no ser simplemente un ORM sino todo un lenguaje conceptual a la hora de desarrollar aplicaciones conectadas a datos.
• Cuando se estima que la aplicación sea escalable y de largo desarrollo en el tiempo. La lógica que se puede derivar de aplicaciones sobre EF es mucho más flexible por lo que se puede extender y escalar fácilmente a medida que el proyecto de software crece.

¿Cuándo L2S?

• Cuando se desarrolla una aplicación de nivel medio y pequeño. Resulta muy cómodo cuando se habla de aplicaciones en Asp.net mvc y casi que se asume como el ORM especial para este framework de desarrollo web. Pero prácticamente en cada escenario en el que el desarrollo esté orientado a datos y sea pequeño o mediano L2S, es una excelente solución pues se tiende a escribir menos código que con EF.
• Cuando se trata de una aplicación que tendrá por back-end un único proveedor de bases de datos. Y ojálá este sea Sql Server. Se han ido desarrollando por terceros proveedores L2S para bases de datos de terceros pero aún se encuentran en fases de desarrollo tempranas.
• Los niveles de abstracción que se usan en la aplicación están casi destinados a coincidir con la persistencia de datos. Aquí es donde L2S, al ser un ORM en sí, lleva la ventaja sobre EF y donde más podemos notar una solución sencilla a la disparidad entre POO y modelo relacional.

En conclusión se habrá notado que tiendo a recomendar EF cuando se trata de aplicaciones corporativas, robustas, escalables y de un alto rigor en la representación de la lógica de negocio. Y L2S me parece una herramienta ideal cuando se trata de aplicaciones de tamaño pequeño y hasta mediano. Esto no significa que no se puedan invertir los escenarios de uso, no, pero quizás sí significa que de hacerlo se subutilicen o sean insuficientes los recursos de uno y otro. Para el framework 4.0 se esperan mejoras importantes en ambos y será necesario entonces revisar estas consideraciones. Quizás se vuelva una cuestión de gustos, simplemente.

Por ahora considero como un excelente término medio Linq to Entities, aunque EF se baste y se sobre por sí mismo.

How to Use the Entity Framework to Update Records in a Relational Database

This quick reference is for those who are using the Entity Framework and want examples of how to perform everyday CRUD tasks. We’ll take a look at how to update objects and associated objects using the Entity Framework.

Quick Reference Setup

Entity Framework & Linq to Entities: “Movies” Example Setup contains diagrams representing the database structure, entity data model, and entity object model used in the following code examples.

Update a Director object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director spikeJonze = _entities.DirectorSet.
               Where(d => d.Name == "Spike Jonze").First();

     spikeJonze.Name = "Adam Spiegel a.k.a \"Spike Jonze\"";
     _entities.SaveChanges();

     Console.ReadLine();
}

First, we retrieve a Director object by specifying a value for the Name property in a lambda expression. Next, we update the Director’s Name property. Finally, we call the ObjectContext’s SaveChanges method to commit the changes to the model and the database.

Using the ObjectStateManager when Updating a Director object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director spikeJonze = _entities.DirectorSet.
               Where(d => d.Name == "Spike Jonze").First();

     spikeJonze.Name = "Adam Spiegel a.k.a \"Spike Jonze\"";

     ObjectStateEntry entry = _entities.ObjectStateManager.
               GetObjectStateEntry(spikeJonze.EntityKey);
     IEnumerable<string$gt; modProps = entry.
               GetModifiedProperties();

     foreach (string prop in modProps)
     {
          Console.WriteLine("Modified Property: {0}",
                    prop.ToString());

          Console.WriteLine("IsDbNull: {0}",
                    entry.OriginalValues.
                    IsDBNull(
                         entry.OriginalValues.GetOrdinal(prop)
                    )
          );

          Console.WriteLine("Changed from: {0}",
                    entry.OriginalValues[prop]);

          Console.WriteLine("Changed to: {0}",
                    entry.CurrentValues[prop]);
     }

     Console.WriteLine("Entity State: {0}", entry.State);

     Console.WriteLine("\n--> All Original Values");
     for (int i = 0; i < entry.OriginalValues.FieldCount; i++)
     {
          Console.WriteLine("{0}: {1}",
                    entry.OriginalValues.GetName(i),
                    entry.OriginalValues[i]);
     }

     _entities.SaveChanges();

     Console.ReadLine();
}

After modifying a property an object, we can use the ObjectStateManager to access state information such as, which properties were modified, those properties original values, their current values, and other helpful information.

To access this information we call the ObjectContext’s GetObjectStateEntry method passing in the Director’s EntityKey. This method returns the ObjectStateEntry for the specified Director object. To determine which properties have been modified, we call the ObjectStateEntries GetModifiedProperties method which returns a collection of the names of any properties whose current values are different from their original values.

To determine the original value of a property, we retrieve the value at a given index in the ObjectStateEntry’s OriginalValues collection. Since OriginalValues is an indexed collection we can specify either the number of the database column or the name of the column (or property) as such, entry.OriginalValues["name"]. We then use the CurrentValues collection to retrieve the current value of the modified property.

Lastly, for the purpose of illustration, we loop over the OriginalValues collection and output all of the Director object’s property names and their respective values.

Here is the output:

Modified Property: Name
IsDbNull: False
Changed from: Spike Jonze
Changed to: Adam Spiegel a.k.a "Spike Jonze"
Entity State: Modified

--> All Original Values
ID: 33
Name: Spike Jonze
Hometown: Rockville Maryland
Birthday: 10/22/1969

How to Use the Entity Framework to Delete Records in a Relational Database

This quick reference is for those who are trying out the Entity Framework and want examples of how to perform everyday CRUD tasks. We’ll take a look at how to delete objects and associated objects using the Entity Framework.

Quick Reference Setup

Entity Framework & Linq to Entities: “Movies” Example Setup contains diagrams representing the database structure, entity data model, and entity object model used in the following code examples.

Delete a Movie object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Movie movieToDelete =
          (from m in _entities.MovieSet
           where m.Title == "The Princess Bride"
	   select m).First();

     _entities.DeleteObject(movieToDelete);
     Console.WriteLine("--> {0}: Marked as Deleted in Model",
          movieToDelete.Title);
     Console.WriteLine("Entity State: {0}",
          movieToDelete.EntityState); // Deleted

     _entities.SaveChanges();
     Console.WriteLine("\n--> {0}:
          Deleted from Model and Datasource",
          movieToDelete.Title);
     Console.WriteLine("Entity State: {0}",
          movieToDelete.EntityState); // Detached
     Console.ReadLine();
}

First we retrieve the Movie we wish to delete. To do so we make use of the First extension method on the Linq query. The First method returns a single object rather than a collection. We then call the ObjectContext’s DeleteObject method passing it the Movie object we retrieved. At this point the ObjectStateManager has marked the object as having a “Deleted” state, though the Movie object has not been deleted from the model or the database. Calling the ObjectContext’s SaveChanges method detaches the Movie from the model and deletes the corresponding record from the database.

Here is the output:

--> The Princess Bride: Marked as Deleted in Model
Entity State: Deleted

--> The Princess Bride: Deleted from Model and Datasource
Entity State: Detached

Delete a Director object and its associated Movie objects using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director spikeJonze = _entities.DirectorSet.
               Where(d => d.Name == "Spike Jonze").First();

     // Remember to Load associated objects
     spikeJonze.Movies.Load(); 

     Console.WriteLine("Number of Movies to Delete: {0}",
               spikesMovies.Count());

     // Using ToList is also important
     foreach (var movie in spikeJonze.Movies.ToList())
     {
          _entities.DeleteObject(movie);
          Console.WriteLine("--> Movie {0}:
                    Marked for Deletion", movie.Title);
     }

     _entities.DeleteObject(spikeJonze);
     Console.WriteLine("--> Director {0}:
               Marked for Deletion", spikeJonze.Name);

     _entities.SaveChanges();
     Console.WriteLine("--> Director and
               associated Movies Deleted");

     Console.ReadLine();
}

We retrieve the Director by passing a lambda expression to the Where extension method and use the First method to specify that we only want the first Movie object in the resulting collection. We then call the Load method on the Director’s Movies collection. This populates any Movies associated with the Director with values retrieved from the database. Each populated Movie object is added to the Movies collection. Neglecting to Load the Movies collection would result in an exception being thrown during the call to SaveChanges. This is because the Movies collection would appear to the ObjectContext to be empty, therefore, none of the Movies would be deleted. However, when SaveChanges is called, it would be determined that the Director does indeed have associated Movies in the database, and could therefore, not be deleted. Using the technique described in this example requires that objects must be loaded in order to be deleted.

Now that we have the Movies associated with the Director, we can loop over the collection and delete each Movie. Notice that the ToList extension method is called on the Director’s Movies collection. Doing so ensures that we are working with a separate instance of the Movies collection. If we tried to perform a delete operation on items in the actual collection we were iterating through, we would receive an error.

Once the Director’s Movies have been marked for deletion, we mark the Director for deletion as well. The subsequent call to the ObjectContext’s SaveChanges method results in the Director and his associated Movies being detached from the ObjectContext and deleted from the database.

Here is the output:

--> Number of Movies to Delete: 4

--> Movie Adaptation: Marked for Deletion
--> Movie Where the Wild Things Are: Marked for Deletion
--> Movie Human Nature: Marked for Deletion
--> Movie Being John Malkovich: Marked for Deletion

--> Director Spike Jonze: Marked for Deletion

--> Director and Associated Movies Deleted

Delete a Movie object without loading it using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     int movieID = 105;
     int directorID = 2;

     Movie princessBride = new Movie();
     princessBride.ID = movieID;
     princessBride.DirectorReference.EntityKey =
               new EntityKey("MovieEntities.DirectorSet",
                         "ID", directorID);

     _entities.AttachTo("MovieEntities.MovieSet",
               princessBride);
     _entities.DeleteObject(princessBride);
     _entities.SaveChanges();

     Console.ReadLine();
}

Assuming we know the ID of a Movie object, we can delete it without having to load it into the ObjectContext. We do so by creating a new Movie object, setting its ID property to the known value, and creating the EntityKeys for any EntityReferences the object may have. We then pass the Movie object to the ObjectContext’s AttachTo method, delete the object, and save the changes.

Unfortunately, I’ve not yet discovered a way to delete objects based on a property value, such as Movie.DirectorID, without loading the objects into the ObjectContext or performing a Linq query, both of which would require a call to the database. If you are aware of a method for doing so, please leave a comment and let us all know.

Exploring EntityStates when Deleting a Movie object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Movie movieToDelete =
          (from m in _entities.MovieSet
           where m.Title == "The Princess Bride"
	   select m).First();

     // Movie retrieved
     Console.WriteLine("--> {0}: Movie Retrieved",
          movieToDelete.Title);
     Console.WriteLine("Entity State: {0}",
          movieToDelete.EntityState); // Deleted

     EntityKey movieToDeleteKey = _entities.
          CreateEntityKey("MovieEntities.MovieSet",
                                   movieToDelete);
     Console.WriteLine("Movie's EntityKey Value: {0}",
          movieToDeleteKey.EntityKeyValues[0].Value);
     Console.WriteLine("DirectorReference
          EntityKey is null: {0}",
          movieToDelete.DirectorReference.EntityKey == null);
     Object deletedMovie = null;
     bool movieToDeleteExists = _entities.
          TryGetObjectByKey(movieToDeleteKey,
               out deletedMovie);
     Console.WriteLine("Movie to Delete Exists
          in ObjectContext: {0}",
          movieToDeleteExists);

     // Movie marked for deletion
     _entities.DeleteObject(movieToDelete);
     Console.WriteLine("\n\n--> {0}: Marked as Deleted in Model",
          movieToDelete.Title);
     Console.WriteLine("Entity State: {0}",
          movieToDelete.EntityState); // Deleted

     movieToDeleteKey = _entities.
          CreateEntityKey("MovieEntities.MovieSet",
               movieToDelete);
     Console.WriteLine("Movie's EntityKey Value: {0}",
          movieToDeleteKey.EntityKeyValues[0].Value);
     Console.WriteLine("DirectorReference
          EntityKey is null: {0}",
          movieToDelete.DirectorReference.EntityKey == null);
     deletedMovie = null;
     movieToDeleteExists = _entities.
          TryGetObjectByKey(movieToDeleteKey,
               out deletedMovie);
     Console.WriteLine("Movie to Delete Exists
          in ObjectConext: {0}",
          movieToDeleteExists);

     // Movie detached from model and deleted from database
     _entities.SaveChanges();
     Console.WriteLine("\n\n--> {0}:
          Deleted from Model and Datasource",
          movieToDelete.Title);
     Console.WriteLine("Entity State: {0}",
          movieToDelete.EntityState); // Detached

     movieToDeleteKey = _entities.
          CreateEntityKey("MovieEntities.MovieSet",
               movieToDelete);
     Console.WriteLine("Movie's EntityKey Value: {0}",
          movieToDeleteKey.EntityKeyValues[0].Value);
     Console.WriteLine("DirectorReference
          EntityKey is null: {0}",
          movieToDelete.DirectorReference.EntityKey == null);
     deletedMovie = null;
     movieToDeleteExists = _entities.
          TryGetObjectByKey(movieToDeleteKey,
               out deletedMovie);
     Console.WriteLine("Movie to Delete Exists
          in ObjectContext: {0}",
          movieToDeleteExists);

     Console.ReadLine();
}

After marking the Movie for deletion, we are still able to make use of the object. In this case we grab the Movies EntityKey and make a call to the ObjectContext’s TryGetObjectByKey method. This method returns true if a Movie with the specified EntityKey exists in the model. It also creates a reference to the Movie and places it in the out parameter deletedMovie.

Calling the ObjectContext’s SaveChanges method detaches the Movie object from the model. The object retains its data values including its EntityKey, however, any relationships it might have had (such as the relationship used for the DirectorReference in this case) are lost. We are still able to retrieve the EntityKey from the detached object, however, the subsequent call to TryGetObjectByKey returns false because the Movie is no longer part of the ObjectContext.

Here is the output:

--> The Princess Bride: Movie Retrieved
Entity State: Unchanged
Movie's EntityKey Value: 97
DirectorReference EntityKey is null: False
Movie to Delete Exists in ObjectContext: True

--> The Princess Bride: Marked as Deleted in Model
Entity State: Deleted
Movie's EntityKey Value: 97
DirectorReference EntityKey is null: True
Movie to Delete Exists in ObjectContext: True

--> The Princess Bride: Deleted from Model and Datasource
Entity State: Detached
Movie's EntityKey Value: 97
DirectorReference EntityKey is null: True
Movie to Delete Exists in ObjectContext: False

How to Use the Entity Framework to Create Records in a Relational Database

This quick reference is for those who are trying out the Entity Framework and want examples of how to perform everyday CRUD tasks. We’ll take a look at how to create objects and manage relationships working with the Entity Framework’s occasionally unclear object model.

Quick Reference Setup

Entity Framework & Linq to Entities: “Movies” Example Setup contains diagrams representing the database structure, entity data model, and entity object model used in the following code examples.

Create a Director object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director spikeJonze = Director.CreateDirector(
          0,
          "Spike Jonze",
          "Rockville Maryland",
          "10/22/1969"
     );

     // Use the AddToDirectorSet method
     _entities.AddToDirectorSet(spikeJonze);

     // Could have also used the AddObject method
     // _entities.AddObject("MovieEntities.DirectorSet",
     //     spikeJonze);

     Console.WriteLine("--> Director added to DirectorSet");
     Console.WriteLine("EntityKey is temporary: {0}",
          spikeJonze.EntityKey.IsTemporary);

     _entities.SaveChanges();

     Console.WriteLine("--> Changes Saved");
     Console.WriteLine("EntityKey is temporary: {0}",
          spikeJonze.EntityKey.IsTemporary);
     Console.WriteLine("EntityKey Key: {0},
          EntityKey Value: {1}",
          spikeJonze.EntityKey.EntityKeyValues[0].Key,
          spikeJonze.EntityKey.EntityKeyValues[0].Value);

     Console.ReadLine();
}

We use the CreateDirector to initialize a new Director object. Notice that 0 is specified for the ID parameter. Though this argument is required, the value you provide is of no consequence. Once the Director is added to the DirectorSet, a temporary EntityKey is created. The call to SaveChanges adds the Director object’s data values to the database and the primary key resulting from the database insert is retrieved. From that point on the EntityKey’s value will be synchronized with the identity column for the Director record in the database.

There are multiple ways to add an entity object to the ObjectContext. Two of which are illustrated in this example. Which method you choose is a matter of preference.

Here is the output:

--> Director added to DirectorSet
EntityKey is temporary: True
--> Changes Saved
EntityKey is temporary: False
EntityKey Key: ID, EntityKey Value: 27

Create a Director object and an associated Movie object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director spikeJonze = new Director {
          Name = "Adam Spiegel a.k.a., Spike Jonze",
          Hometown = "Rockville Maryland",
          Birthday = "10/22/1969"
     };
     _entities.AddToDirectorSet(spikeJonze);

     Movie wildThings = new Movie {
          Title = "Where the Wild Things Are",
          DateReleased = DateTime.Parse("10/1/2009")
     };
     spikeJonze.Movies.Add(wildThings);

     _entities.SaveChanges();
     Console.ReadLine();
}

We use object initialization syntax to create a Director object and then add it to the ObjectContext’s DirectorSet collection. We then create a Movie object and add it to the Director’s Movies collection. Doing so creates a relationship (with corresponding temporary EntityKeys) between the Director and the Movie. Calling the SaveChanges method updates the database to reflect the changes we’ve made to the entity data model.

There are multiple ways to initialize object in CSharp. When working with the Entity Framework, I prefer to use object initialization syntax (used in this example) in lieu of using the CreateDirector factory method. Though there is a benefit to using the factory method in that you are forced to provide initial values for all properties. What you use is a matter of preference.

Create a Movie object and associate it with an existing Director object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director robReiner = _entities.DirectorSet.Where(
               d => d.Name == "Rob Reiner").First();

     Movie thePrincessBride = new Movie {
          Title = "The Princess Bride",
          DateReleased = DateTime.Parse("1/1/1987")
     };

     robReiner.Movies.Add(thePrincessBride);
     _entities.SaveChanges();
     Console.ReadLine();
}

First we load the appropriate Director object. Next we create the Movie object and add it to the Director’s Movies collection. Doing so creates the necessary relationship. Finally, we call the ObjectContext’s SaveChanges() method which inspects the context’s ObjectStateManager and commits any changes that had been made to the model’s entities or associations since it was created or since SaveChanges() was last called.

Create a Movie object and associate it with an existing Director object without loading the Director object using the Entity Framework

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     int robReinerID = 2;
     Movie thePrincessBride = new Movie {
          Title = "The Princess Bride (New)",
          DateReleased = DateTime.Parse("1/1/1987")
     };

     thePrincessBride.DirectorReference.EntityKey = new
          EntityKey("MovieEntities.DirectorSet",
                    "ID", robReinerID);
     _entities.AddToMovieSet(thePrincessBride);
     _entities.SaveChanges();
     Console.ReadLine();
}

Since we know the Director’s ID, there is no need to load the Director object in order to create the Movie. It is necessary, however, to set the EntityKey property of the DirectorReference (an EntityReference type). Note that the first argument passed to the EntityKey’s constructor is an EntitySet within the ObjectContext; e.g., MovieEntities.DirectorSet.

Exploring the Entity Framework’s ObjectStateManager

private static MovieEntities _entities = new MovieEntities();

static void Main(string[] args)
{
     Director robReiner = _entities.DirectorSet.Where(
               d => d.Name == "Rob Reiner").First();

     Movie thePrincessBride = new Movie {
          Title = "The Princess Bride",
          DateReleased = DateTime.Parse("1/1/1987")
     };

     robReiner.Movies.Add(thePrincessBride);
     IEnumerable<ObjectStateEntry> entries =
          _entities.ObjectStateManager.
          GetObjectStateEntries(EntityState.Added);

     foreach (ObjectStateEntry entry in entries)
     {
          Console.WriteLine("Entity Set: {0}", entry.EntitySet);
	  Console.WriteLine("IsRelationship: {0}",
               entry.IsRelationship);
	  Console.WriteLine("State: {0}", entry.State);

	  if (!entry.IsRelationship)
	  {
	     Console.WriteLine("EntityKey is null: {0}",
                  entry.EntityKey.EntityKeyValues == null);
             Console.WriteLine("EntityKey is temporary: {0}",
                  entry.EntityKey.IsTemporary);
	  }

          entry.AcceptChanges();
          Console.WriteLine("--> Changes Accepted");

	  if (!entry.IsRelationship)
	  {
	        Console.WriteLine("EntityKey is: {0}",
                     entry.EntityKey.EntityKeyValues.First());
		Console.WriteLine("EntityKey is temporary: {0}",
                     entry.EntityKey.IsTemporary);
	  }

          Console.WriteLine("State: {0}\n\n", entry.State);
     }

     // The following call to SaveChanges() does nothing
     // because calling AcceptChanges() on each entry updated
     // their respective states from "Added" to "Unchanged".
     _entities.SaveChanges(); 

     Console.ReadLine();
}

First we add a Movie to a Director’s collection of Movies. Doing so adds two ObjectStateEntries to the ObjectStateManager. ObjectStateEntries are used to track changes made to the entity model. One of the entries is for the Movie entity that was added and the second is for the relationship that was created between the Movie and the Director. We then grab the ObjectStateEntries where the EntityState equals “Added”. Looping over the ObjectStateEntries allows us to see various properties of the entries before and after AcceptChanges is called. When AcceptChanges is called on a given entry, its state is set to “Unchanged”. Therefore, the subsequent call to SaveChanges does nothing since the state of all ObjectStateEntries is “Unchanged” at the time SaveChanges is called. Retrieving a list of Movies would reveal that the Movie was not inserted into the database.

Here is the output:

Entity Set: FK_Movies_Directors
IsRelationship: True
State: Added
--> Changes Accepted
State: Unchanged

Entity Set: MovieSet
IsRelationship: False
State: Added
EntityKey is null: True
EntityKey is temporary: True
--> Changes Accepted
EntityKey is: [ID, 0]
EntityKey is temporary: False
State: Unchanged