ASP.NET MVC with ADO.NET Entity Framework

2

January 23, 2009 by temebele

BACKGROUND

Last week, I started working on a new project where I decided to use the new .NET 3.5 features. Microsoft has changed the way we approach web development with the traditional ASP.NET. Also data access with ADO.NET Entity framework is far different from using the ADO.NET Data providers directly.

Because of this I created this blog post to help me track the decisions that I go through on every step of this project. It will help me go back and review my decisions, also can be a good source for developers who plan to use this new features in the future.


LAYERING

ADO.NET Entity Framework has an ORM tool that helps you map the storage model into a conceptual model. It also helps you logically group the Business Entities and Data Access Component with namespaces.

Now that the Business Entities live inside the data layer, my presentation layer is going to have dependency on the data layer. Since I can also implement business rules using partial classes, I’m inclining more to using a two layered approach.

I have opened up this discussion on asp.net forum to get idea from people, if it is really important to have a business layer or not. You can track the discussions on: forums.asp.net/t/1374529.aspx

At the start of projects, I always had the inclination to create separate projects, hence have different physical packaging units for each layer. I started researching about the different ways of Layering and found a really good article by Martin Fowler. The article discusses about a pattern of layering called “Separated Presentation” where we keep the presentation code and domain code in separate layers with the domain code unaware of the presentation code. I thought separated presentation really fits with my MVC implementation.

Below is excerpt from Fowler

Further layering is often used to separate data source code from domain (business logic), and to separate the the domain using a Service Layer. For the purposes of Separated Presentation we can ignore these further layers, just referring to all of this as ‘the domain layer’. Just bear in mind that further layering of the domain layer is likely.

The layers are a logical and not a physical construct. Certainly you may find a physical separation into different tiers but this is not required (and a bad idea if not necessary). You also may see a separation into different physical packaging units (eg Java jars or .NET assemblies), but again this isn’t required. Certainly it is good to use any logical packaging mechanisms (Java packages, .NET name spaces) to separate the layers.

As well as a separation, there is also a strict visibility rule. The presentation is able to call the domain but not vice-versa. This can be checked as part of a build with dependency checking tools. The point here is that the domain should be utterly unaware of what presentations may be used with it. This both helps keep the concerns separate and also support using multiple presentations with the same domain code.

http://martinfowler.com/eaaDev/SeparatedPresentation.html

Unless I found a really convincing reason, I’m just going with two projects for now, one for my presentation and one for my data access. Remember, the data access framework (EF) has already flexibility to logically group my domains from the data access components by using namespaces. I will have to modify my build scripts to check for unintended dependency at some point if I have to.

The next question I had was if I need the flexibility to be able to plug in different data providers in the future. I’m quite confident that the infrastructure services won’t change much in the future. We will be using SQL Server to persist the state of our business entities and I don’t see that changing in the near future. But hey it doesn’t really hurt to have the flexibility in there. (It is also not too much effort to do it now than worry about it after the project gets big.)

So I have decided to use Repository Pattern for my data access.

“Repository mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.

http://martinfowler.com/eaaCatalog/repository.html

EF Diagram

Well looking at the definition of a repository, with ADO.NET Entity Framework that is exactly what the Object Context does for us.

The Object Context has:

  • in-memory domain object collection
  • Client object can create a query and submit to the Object Context
  • Objects can be added to and removed from the Repository
  • Provides a more object-oriented view of the persistence layer.

So do I really need to create another repository layer on top of the Object Context?

Well I have finally decided that there is a need for flexibility to be able to return a collection of the business Entities without the client knowing about the implementation. For that I have created another Interface layer on top of the Object Context. I don’t know if that should be called Repository because it really doesn’t fit with the definition of Repository Pattern.
It is more like a factory that is just used to avoid the dependency of clients on implementation, so that they Clients can inject their own implementation in the future if need be. For that reason I am naming my interfaces gateway instead of repository.

After some research, I found Jarosalaw Kowalski’s blog where he talks about adding a POCO support to EF.
POCO(Plain old CLR objects) is another persistence ignorant model layer. The POCO adapter knows how to translate the domains from the plain objects to the conceptual model. It also allows lazy loading. With all that in mind, I still didn’t want to add any complexity to my project by adding POCO support. Since I don’t anticpate using a different ORM tool in the future, I’m just gonna stick to using the EF business entities in the presentation model.


Till today (Jan 28th), I have been developing my presentation layer with ASP.NET MVC. I hate to admit it but it really costs your time to be any early adopter for a technology.  Getting information from blogs and articles and building reusable HTML helpers kinda takes sometime. I love the amount of control that I get with MVC but then until you have a good helper library for all your HTML needs, it kinda affects productivity.  MVC Contrib on codeplex have developed many cool Html helpers but didn’t want to go that route and blindly add another community framework and start using it right away. Well  If we keep adding many helper libaries,  then we gonna keep losing the full control that we got through this new framework. So…we will see how it goes in the next few days. Project is due soon. I will keep you updated.


So I got in the morning and kept working on my MVC app. In addition to the additional effort to build reusable Html helpers, deploying to IIS6.0 also became an issue. I didn’t notice it so far because I was just testing with the built in development server on Visual Studio.

If you are deploying your MVC app to IIS 6.0, you have to go through certain hacks.

Deploying ASP.NET MVC on IIS 6

Unfortunately both my local server and staging server are running IIS 6.0.

Even on IIS 7.0, there are certain settings that you have to change to fully utilize extensionless Urls.

Deploying an ASP.Net MVC web application to IIS7

Well project is due in two weeks, I think I got enough reason to switch back to using page-controller (traditional asp.net) and finish up my project on time. I will try to finish up my MVC start up offline outside project hours.

In summary, I think MVC is the way to go for web development. It gives the developer so much control and the separation of concerns makes team work a lot easier. Once you test the flavors of web development with MVC, you just never wanna go back to your old way of doing things.


Now I’m 25% into my implementation. I started using ADO.NET EF just from reading articles, MSDN and blogs. As you start applying it to solve real problems in your projects, you ran into issues (e.g performance, memory utilization) here and there unless you have the big picture of how the EF architecture looks like.
So I decided that it will be helpful if I go back and read a book on Entity Framework. After some research I was able to find Programming Entity Framework, 1st Edition . It is a great book and I recommend it for any one who is just starting to learn and apply ADO.NET EF on their projects. You can read it online on http://my.safaribooksonline.com. I just subscribed for the trial membership. The trial membership lasts 10 days. It has only been few hours since I subscribed it and I have pretty much got what I need from this book. Correct me if I am wrong but in my opinion a good software developer should be able to read a full technology book in just few hours (a day max) and have a good grasp of what they were looking to learn from that material. Otherwise if you don’t train yourself in being a fast reader, it will start interfering with your project hours. I believe most software developers are hired to deliver some result to the business and not to explore knowledge 24hrs like a school professor. Hey…Sorry but we don’t have that luxury  at least I know I don’t. 🙂


Advertisements

2 thoughts on “ASP.NET MVC with ADO.NET Entity Framework

  1. Russell East says:

    Sounds like you are on the right path. I would use a repository layer above EF. as EF is a technology and by providing your own interface you have a layer of abstraction, plus its makes code more testable. I would also have a layer between the UI and the repositories (service layer). I would not expose my domain entities above the service layer and use “Data Transfer objects (DTOs)” to pass data between layers (ideally request/response objects). This requires that each layer maps a DTO to a type that it knows about. Would you have as a layer that only knows about the layer directly below it. I may seem a lot more work but you will make your application more testable, loosely coupled and lot earlier to maintain. If you haven’t already, research Domain driven design.

  2. temebele says:

    Russel thanks for the comments.

    According to Domain Driven Design, your domain layer should be ignorant about the persistence, which I completely agree. But then you have additional complexity of mapping from the plain old CLR objects to the conceptual model. Jarosalaw Kowalski has a sample application where he shows how to have POCO support with the current Entity Framework.

    But for the project I’m working on, since I don’t really expect changes in the future for infrastructure services (where data is stored), I’m just gonna stick to a two layer approach where I use the Business Entities in my presentation. Then once Microsoft comes up with EF version 2 with POCO support, I will refactor it to use that.
    What are you currently using for your POCO support?

    According to what I read, DTOs are not that popular any more in DDD. You want your domain objects to have the domain logic to the fullest and the service layer should be so lean, as opposed to the old DTO way where the domain are just data containers and the service layer holds the business logic. I try to minimize the use of DTOs only for my passing data between my views and controllers.

    I have that repository interface layer above EF, which really gives me flexibility to have different implementation for fetching data. But looking at Fowler’s definition for Repository, I thought I should call it a interface gateways than repository. I see it being called repository in many projects, but according to how I interpreted Fowler’s definition for Repository Pattern, I thought it would be better to call them a gateway than repository.

    Let me know what you think

    Thanks,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: