Although nHydrate is only a year old from an open source perspective, it was originally created over five years ago on the .Net 1.1 framework. During this time, nHydrate sets out to enhance the data access experience using a Model Driven Architecture (MDA) approach. Using this approach required us to provide a model at a higher level of abstraction than a typical data access layer. Our core focus was to ease the pains of evolutionary database design while maintaining a robust data access layer (DAL).
The nHydrate team has always been dedicated to staying up with the latest Microsoft technologies. As a team, we do not wish to be stuck on an out of date technology. Over the past couple of years, we have watched carefully as Entity Framework (EF) has evolved. It was not until the release of 4.0 that we felt it would be viable for us to provide an EF solution. The advent of a viable Entity Framework architecture, also allowed us to demonstrate the flexibility of a MDA based application. Using the same model, developers can generate very different DAL solutions.
At this point I feel it is important to identify our continued dedication to the current Data Access Layer (DAL). There are many applications in production today that depend on this architecture. Entity Framework 4.0 is not a good solution for many of them. Specifically, applications that wish to provide a DAL that consists of hundreds of tables. For these reasons the current solution is core to what we do and must continue to be a focus.
To get a good answer to this question you must look at our past. The majority of our current architecture is built on Dataset technology. When we originally investigated this technology two things became evident. First, the models that drove the dataset were created at the project level. We felt that an MDA based application should have a model at the solution level. Second, there were several improvements that could be built on top of this architecture. Anyone who looks at the nHydrate architecture today would verify that it has many advantages over strait datasets. Entity Framework is not an exception to either of these realizations.
Taking a more concrete look at the current EFDAL release the following items are addressed:
- Evolutionary database management – The current database product has been adjusted to capture the needs of the Entity Framework model. The nHydrate team is bringing evolutionary database concepts to an Entity Framework solution. For those using nHydrate today, another important realization should be made. The EFDAL and the nHydrate DAL can on the same database. Making a mixed implementation possible today and a migration path available in the future.
- Type Tables – Managing enumerations in your code and database can be a cumbersome task. nHydrate solves this by allowing users to define type tables that present themselves as enumerations in the DAL. Example: In the Order table we need to persist an Order Status column that represents one of the following values Created, Packaged, Shipped, or Received. The management of this enumeration in the code can be handled by adding a type table to the nHydrate model.
- Stored Procedure Generation – All insert, update and delete functions are automatically mapped to stored procedures.
- Property Level Eventing – The entity objects are provided with an event model that allows users to hook into specific property changes.
- Explicit partial class generation – If you have used our generator in the past you would notice that we like to generate an editable partial class file as a parent to the code generation file. In the below example the Customer.cs file contains a partial class that is used to extend the generated Customer object in Customer.Generated.cs file.
- Convenience property for derived table – An example of querying the derived shape circle is below.
- Implicit Load - Automated calls to load method the first time a property is walked.
To learn more please download the sample project at http://bit.ly/c9PmCz. Also, follow us on twitter or join our linked in group. More documentation and examples will be provided through our blog, the code project, CodePlex and You Tube. The best ways to monitor these events is to follow our twitter feed or subscribe to the LinkedIn group. The side of this blog provides a link to these social networking sites.
The majority of this question will be answered by the users that provide us with feedback. However, there are a few things that we must support. First, we must provide a solution that provides a transition path between the competing data access layers. Second, we have a short list of features that we wish to support on Entity Framework over the next few weeks:
- Auditing – Modifier established at context level, Creation of audit tables automatically filled through create, update and delete operations.
- Bulk operations - update, insert and delete
- Generation of a RIA services project.