January 23, 2009 by temebele
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.
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.
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.“
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.“
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.
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.
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. 🙂