I have been using Entity Framework and the repository pattern for some time now.
I was asked the other day to write a data layer without using Entity Framework, just plain old ADO.NET. I was wondering what would be the best approach for this? Do I also use a repository pattern for my CRUD operations using plain old ADO.NET?
If I go to Codeplex and search for repository pattern then 99.9% of all the sample projects use Entity Framework. Is there a different pattern that needs to be used if I use plain ADO.NET with stored procedures?
No, the repository pattern is used extensively outside of the Entity Framework, and is an all round useful way of handling data access.
From MSDN
It centralizes the data logic or Web service access logic.
It provides a substitution point for the unit tests.
It provides a flexible architecture that can be adapted as the overall design of the application evolves.
http://msdn.microsoft.com/en-us/library/ff649690.aspx
Other benefits:
Simple to add logic in the repository, such as caching results over a web request
Common query's can be added, such as userRepository.FindByEmailAddress(emailAddress);
Repository can be changed out with another, such as switching a dabase to a web service with minimal effort
I don't think this is the right way. But there are some assumptions
Adding a Repository pattern on top of EF code. This keep distances you from the features of your ORM. The Entity Framework is already an abstraction layer over your database.
If you want to use the Dependency Injection and Test Driven Development over EF then you follow the Repository Pattern. By using RP your code become testable and Injectable / maintainable.
Out of the box EF is not very testable, but it's quite easy to make a mockable version of the EF data context with an interface that can be injected.
If we don’t want our code to be testable or injectable then just don’t use RP.
I saw a blog post: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern
Martin Fowler's "Patterns of Enterprise Architecture", provides the following definition for a repository:
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
A common way to implement that in C# is to have a generic Repository<T> class where T is a persistent object that implements IQueryable<T> and provides additional methods like Add(entity), Remove(entity).
It would be very difficult to implement without an ORM. You can make a simpler repository that takes SQL statements as WHERE conditions but it can get messy.
Numerous examples use concrete repository classes for each type with different persistence methods. But those are just disguised DAO classes.
Related
Within my various projects I implement the command/query separation pattern and use NHibernate as my ORM.
In general I keep my commands and queries in separate projects relevant to the particular set of activities such as UserManagement, TagManagement, QuestionManagement etc.
I quite like having everything divided up nicely into these repositories with easily findable functionality. There are certainly benefits in doing things this way.
I am however starting to wonder about the value of this abstraction for basic queries especially given that NHibernate already offers such a powerful abstraction by itself.
Consider this in my MVC controller:
_nHibernateSession.Get<UserProfile>(_sessionData.UserId);
I could abstract this out into a query in the UserManagement repository but I'm not sure what value that offers.
What do you think? Would you keep everything within the command/query paradigm or would you use the nhibernate session directly in your controllers for simple requests like this?
Usually i'm not using repositories, because I think that they are adding too much abstraction into my code. I prefer View Model which is constructed directly in Service / Controller layer. If i want to write a unit test i can write it against service or controller. If you want to reuse some query criteria, then just write extension method:
public static IQueryable<User> Administrators(this IQueryable<User> users)
{
return users.Where(x => x.Role.Id == Role.Const.Admin);
}
Regarding this I recommend these articles:
http://ayende.com/blog/3955/repository-is-the-new-singleton
http://www.planetgeek.ch/2012/05/05/what-is-that-all-about-the-repository-anti-pattern/
I prefer to keep all queries in the repository, if you need to make a lot of different query you can expose the a repository that implements an IQueryable and wrap session.Query of LINQ To Nhibernate, that has limitations respect to HQL or Criteria.
But for me there isn't a valid reason to make this, only if you are providing a Data Access Layer to somebody else and you will not know the queries.
You can see an example of this on a DDD project I'm working.
I would strongly encourage you to maintain a level of abstraction between your MVC controller and NHibernate, especially if you need to do unit testing of your MVC controller. Without the repository layer, it is far more difficult to create Unit tests which require mocking of the repository layer.
I am looking for a discussion on the use of ORMs in fashion where one could swap out the ORM you are using with a minimal impact on the rest of the system.
I guess if you were using MVP, your view and presenter would have no idea (no references) to whatever ORM you are using. I think the best that I came up with is a Service class that uses some IRepository. And the concrete repository returns DTOs to the service class. You would have a concrete repository implementation for each ORM that you use. I would also ask how you would manage the mappings between the ORM objects/entities and the DTOs efficiently.
I guess I would like to free the majority of the application from depending on a specific ORM.
Does anyone have a link to a blog/whitepaper discussing this topic?
Like you said, hiding the ORM used is a perfect job for the Repository Pattern.
I'm implementing a DAL using entity framework. On our application, we have three layers (DAL, business layer and presentation). This is a web app. When we began implementing the DAL, our team thought that DAL should have classes whose methods receive a ObjectContext given by services on the business layer and operate over it. The rationale behind this decision is that different ObjectContexts see diferent DB states, so some operations can be rejected due to problems with foreign keys match and other inconsistencies.
We noticed that generating and propagating an object context from the services layer generates high coupling between layers. Therefore we decided to use DTOs mapped by Automapper (not unmanaged entities or self-tracking entities arguing high coupling, exposing entities to upper layers and low efficiency) and UnitOfWork. So, here are my questions:
Is this the correct approach to design a web application's DAL? Why?
If you answered "yes" to 1., how is this to be reconciled the concept of DTO with the UnitOfWork patterns?
If you answered "no" to 1., which could be a correct approach to design a DAL for a Web application?
Please, if possible give bibliography supporting your answer.
About the current design:
The application has been planned to be developed on three layers: Presentation, business and DAL. Business layer has both facades and services
There is an interface called ITransaction (with only two methods to dispose and save changes) only visible at services. To manage a transaction, there is a class Transaction extending a ObjectContext and ITransaction. We've designed this having in mind that at business layer we do not want other ObjectContext methods to be accessible.
On the DAL, we created an abstract repository using two generic types (one for the entity and the other for its associated DTO). This repository has CRUD methods implemented in a generic way and two generic methods to map the DTOs and entities of the generic repository with AutoMapper. The abstract repository constructor takes an ITransaction as argument and it expects the ITransaction to be an ObjectContext in order to assign it to its proctected ObjectContext property.
The concrete repositories should only receive and return .net types and DTOs.
We now are facing this problem: the generic method to create does not generate a temporal or a persistent id for the attached entities (until we use SaveChanges(), therefore breaking the transactionality we want); this implies that service methods cannot use it to associate DTOs in the BL)
There are a number of things going on here...The assumption I'll make is that you're using a 3-Tier architecture. That said, I'm unclear on a few design decisions you've made and what the motivations were behind making them. In general, I would say that your ObjectContext should not be passed around in your classes. There should be some sort of manager or repository class which handles the connection management. This solves your DB state management issue. I find that a Repository pattern works really well here. From there, you should be able to implement the unit of work pattern fairly easily since your connection management will be handled in one place. Given what I know about your architecture, I would say that you should be using a POCO strategy. Using POCOs does not tightly couple you to any ORM provider. The advantage is that your POCOs will be able to interact with your ObjectContext (probably via Repository of some sort) and this will give you visibility into change tracking. Again, from there you will be able to implement the Unit of Work (transaction) pattern to give you full control over how your business transaction should behave. I find this is an incredibly useful article for explaining how all this fits together. The code is buggy but accurately illustrates best practices for the type of architecture you're describing: Repository, Specification and Unit of Work Implementation
The short version of my answer to question number 1 is "no". The above link provides what I believe to be a better approach for you.
I always believed that code can explain things better than worlds for programmers. And this is especially true for this topic. Thats why I suggest you to look at the great sample application in witch all consepts you expecting are implemented.
Project is called Sharp Architecture, it is centered around MVC and NHibernate, but you can use the same approaches just replacing NHibernate parts with EF ones when you need them. The purpose of this project is to provide an application template with all community best practices for building web applications.
It covers all common and most of the uncommon topics when using ORM's, managing transactions, managing dependencies with IoC containers, use of DTOs, etc.
And here is a sample application.
I insist on reading and trying this, it will be a real trasure for you like it was for me.
You should take a look what dependency injection and inversion of control in general means. That would provide ability to control life cycle of ObjectContext "from outside". You could ensure that only 1 instance of object context is used for every http request. To avoid managing dependencies manually, I would recommend using StructureMap as a container.
Another useful (but quite tricky and hard to do it right) technique is abstraction of persistence. Instead of using ObjectContext directly, You would use so called Repository which is responsible to provide collection like API for Your data store. This provides useful seam which You can use to switch underlying data storing mechanism or to mock out persistence completely for tests.
As Jason suggested already - You should also use POCO`s (plain old clr objects). Despite that there would still be implicit coupling with entity framework You should be aware of, it's much better than using generated classes.
Things You might not find elsewhere fast enough:
Try to avoid usage of unit of work. Your model should define transactional boundaries.
Try to avoid usage of generic repositories (do note point about IQueryable too).
It's not mandatory to spam Your code with repository pattern name.
Also, You might enjoy reading about domain driven design. It helps to deal with complex business logic and gives great guidelines to makes code less procedural, more object oriented.
I'll focus on your current issues: To be honest, I don't think you should be passing around your ObjectContext. I think that is going to lead to problems. I'm assuming that a controller or a business service will be passing the ObjectContext/ITransaction to the Repository. How will you ensure that your ObjectContext is disposed of properly down stream? What happens when you use nested transactions? What manages the rollbacks, for transactions down stream?
I think your best bet lies in putting some more definition around how you expect to manage transactions in your architecture. Using TransactionScope in your controller/service is a good start since the ObjectContext respects it. Of course you may need to take into account that controllers/services may make calls to other controllers/services which have transactions in them. In order to allow for scenarios where you want full control over your business transactions and the subsequent database calls, you'll need to create some sort of TransactionManager class which enlists, and generally manages transactions up and down your stack. I've found that NCommon does an extraordinary job at both abstracting and managing transactions. Take a look at UnitOfWorkScope and TransactionManager classes in there. Although I disagree with NCommon's approach of forcing the Repository to rely on the UnitOfWork, that could easily be refactored out if you wanted.
As far as your persistantID issue goes, check this out
I need some advice how we can decouple nHibernate dependencies in the presentation layer. Currently we have a three tier C# winforms application consisting (simplified) of the following layers;
User Interface (UI)
Business Logic (BAL)
Data Access Logic (DAL)
We are migrating this application to an ORM (nHibernate) and would ideally like to have only the DAL referencing nHibernate. We also want to employ the "Unit of Work" functionality which is included in nHibernate, adopting a "Session per conversation" methodology.
To achieve this we need to create and open a session in the UI, pass the session through the BAL to the DAL however we cannot achieve this without creating a dependency to nHibernate in both the BAL and DAL.
Any advice would be appreciated. How should we structure the architecture to avoid any references to nHibernate in the UI and BAL. Any ideas?
I must also add that we do not want the UI to have a reference to the DAL either.
UI => BAL => DAL
Impossible to do it that way, since the UnitOfWork pattern is implemented by NHibernate's Session object.
However, you only want to reference NHibernate from your DAL, which is quite useless, since your DAL doesn't know anything about the application's context, and this context is necessary in order to use the UnitOfWork.
Take a look at the NHibernate 3.0 Cookbook I found it quite useful for getting to grips with NHibernate.
You will need to extract your entities and create POCOs (Plain Old CLR Objects). Your UI will not require any knowledge of NHibernate. You will create methods in your Data Layer to manipulate your data.
Configure your IoC container in a separate class library, for example by using the "GuyWire" pattern described here:
http://nhforge.org/blogs/nhibernate/archive/2009/11/07/nhibernate-and-wpf-the-guywire.aspx
I recently built an example of a decoupled architecture using nhibernate in an asp.net mvc application. It uses a repository pattern and a separate unit of work. Most of these concepts should be reusable in a thick client also. Here is a search link on my blog with the posts that may be interesting.
http://blog.bobcravens.com/?s=Nhibernate
Hope this gets you started. Let me know if you have questions.
Bob
I'm writing an application using DDD techniques. This is my first attempt at a DDD project. It is also my first greenfield project and I am the sole developer. I've fleshed out the domain model and User interface. Now I'm starting on the persistence layer. I start with a unit test, as usual.
[Test]
public void ShouldAddEmployerToCollection()
{
var employerRepository = new EmployerRepository();
var employer = _mockery.NewMock<Employer>();
employerRepository.Add(employer);
_mockery.VerifyAllExpectationsHaveBeenMet();
}
As you can see I haven't written any expectations for the Add() function. I got this far and realized I haven't settled on a particular database vendor yet. In fact I'm not even sure it calls for a db engine at all. Flat files or xml may be just as reasonable. So I'm left wondering what my next step should be.
Should I add another layer of abstraction... say a DataStore interface or look for an existing library that's already done the work for me? I'd like to avoid tying the program to a particular database technology if I can.
With your requirements, the only abstraction you really need is a repository interface that has basic CRUD semantics so that your client code and collaborating objects only deal with IEmployerRepository objects rather than concrete repositories. You have a few options for going about that:
1) No more abstractions. Just construct the concrete repository in your top-level application where you need it:
IEmployeeRepository repository = new StubEmployeeRepository();
IEmployee employee = repository.GetEmployee(id);
Changing that in a million places will get old, so this technique is only really viable for very small projects.
2) Create repository factories to use in your application:
IEmployeeRepository repository = repositoryFactory<IEmployee>.CreateRepository();
IEmployee employee = repository.GetEmployee(id);
You might pass the repository factory into the classes that will use it, or you might create an application-level static variable to hold it (it's a singleton, which is unfortunate, but fairly well-bounded).
3) Use a dependency injection container (essentially a general-purpose factory and configuration mechanism):
// A lot of DI containers use this 'Resolve' format.
IEmployeeRepository repository = container.Resolve<IEmployee>();
IEmployee employee = repository.GetEmployee(id);
If you haven't used DI containers before, there are lots of good questions and answers about them here on SO (such as Which C#/.NET Dependency Injection frameworks are worth looking into? and Data access, unit testing, dependency injection), and you would definitely want to read Martin Fowler's Inversion of Control Containers and the Dependency Injection pattern).
At some point you will have to make a call as to what your repository will do with the data. When you're starting your project it's probably best to keep it as simple as possible, and only add abstraction layers when necessary. Simply defining what your repositories / DAOs are is probably enough at this stage.
Usually, the repository / repositories / DAOs should know about the implementation details of which database or ORM you have decided to use. I expect this is why you are using repositories in DDD. This way your tests can mock the repositories and be agnostic of the implementation.
I wrote a blog post on implementing the Repository pattern on top of NHibernate, I think it will benefit you regardless of whether you use NHibernate or not.
Creating a common generic and extensible NHiberate Repository
One thing I've found with persistence layers is to make sure that there is a spot where you can start doing abstraction. If you're database grows, you might need to start implementing sharding and unless there's already an abstraction layer already available, it can be difficult to add one later.
I believe you shouldn't add yet another layer below the repository classes just for the purpose of unit testing, specially if you haven't chosen your persistence technology. I don't think you can create an interface more granular than "repository.GetEmployee(id)" without exposing details about the persistence method.
If you're really considering using flat text or XML files, I believe the best option is to stick with the repository interface abstraction. But if you have decided to use databases, and you're just not sure about the vendor, an ORM tool might be the way to go.