How do I encapsulate the saving of more than one entity in a transactional manner using the repository pattern?  For example, what if I wanted to add an order and update the customer status based on that order creation, but only do so if the order completed successfully?  Keep in mind that for this example, orders are not a collection inside the customer.  They are their own entity.

This is just a contrived example, so I don’t really care whether orders should or should not be inside the customer object or even in the same bounded context.  I don’t really care what underlying technology will be used (nHibernate, EF, ADO.Net, Linq, etc.)  I just want to see what some calling code might look like in this admittedly contrived example of an all or nothing operation.


Transactions in the Repository Pattern

I have created a POCO model class and a repository class which handles persistence.  Since the POCO cannot access the repository, there are lots of business logic tasks in the repository which doesn&#39;t seem right.  From what I have read, it looks like I need a service layer that sits between the UI consumers and the repository layer.  What I am not sure of is exactly how it is supposed to work...

In addition to the service layer, should there also be a separate business logic layer, or is that the role of the service layer?

Should there be one service per repository?

Is the service layer the only way that the UI can instance the model objects or does the repository provide the new model instance to the service?

Do I put my parameter, model and other validations in the service layer that do things like check to make sure a input is valid and that a item to update exists in the database before updating?  

Can the model, repository and UI all make calls to the service layer, or is it just for the UI to consume?

Is the service layer supposed to be all static methods?

What would be a typical way to call the service layer from the UI?

What validations should be on the model vs the service layer?


Here is some sample code for my existing layers:

    public class GiftCertificateModel
    {
        public int GiftCerticiateId {get;set;}
        public string Code {get;set;}
        public decimal Amount {get;set;}
        public DateTime ExpirationDate {get;set;}

        public bool IsValidCode(){}
    }


    public class GiftCertificateRepository
    {
        //only way to access database
        public GiftCertificateModel GetById(int GiftCertificateId) { }
        public List&lt;GiftCertificateModel&gt; GetMany() { }
        public void Save(GiftCertificateModel gc) { }
        public string GetNewUniqueCode() { //code has to be checked in db }

        public GiftCertificateModel CreateNew()
        {
            GiftCertificateModel gc = new GiftCertificateModel();
            gc.Code = GetNewUniqueCode();
            return gc;
        }              
    }


**UPDATE:** 
I am currently using web forms and classic ADO.NET.  I hope to move to MVC and EF4 eventually.


**UPDATE:** Big thanks to @Lester for his great explanation.  I now understand that I need to add a service layer for each of my repositories.  This layer will be the ONLY way the UI or other services can communicate with the repository and will contain any validations that do not fit on the domain object (eg - validations that need to call the repo)

    public class GiftCertificateService()
    {

        public void Redeem(string code, decimal amount)
        {
            GiftCertificate gc = new GiftCertificate();
            if (!gc.IsValidCode(code))
            {
                throw new ArgumentException(&quot;Invalid code&quot;);
            }
            
            if (amount &lt;= 0 || GetRemainingBalance(code) &lt; amount)
            {
                throw new ArgumentException(&quot;Invalid amount&quot;);
            }

            GiftCertificateRepository gcRepo = new GiftCertificateRepository();
            gcRepo.Redeem(code, amount);
        }

        public decimal GetRemainingBalance(string code)
        {
            GiftCertificate gc = new GiftCertificate();            
            if (!gc.IsValidCode(code))
            {
                throw new ArgumentException(&quot;Invalid code&quot;);
            }

            GiftCertificateRepository gcRepo = new GiftCertificateRepository();
            gcRepo.GetRemainingBalance(code);
        }

        public SaveNewGC(GiftCertificate gc)
        {
            //validates the gc and calls the repo save method
            //updates the objects new db ID
        }

    }

**Questions**

1. Do I add the same (and possibly more) properties to the service as I have on my model (amount, code, etc) or do I only offer methods that accept GiftCertificate objects and direct parameters? 

2. Do I create a default instance of the GiftCertificate entity when the Service constructor is called or just create new ones as needed (eg - for validation methods in the service that need to call validation methods in the entity?  Also, same  question about creating a default repository instance...?

3. I know i expose the functionality of the repo via the service, do I also expose the methods from the entity as well (eg - IsValidCode, etc)?

4. It is ok for the UI to simply create a new GiftCertificate object directly without going through the service (eg - to call parameter validation methods from the entity).  If not, how to enforce it?

5. On the UI layer, when I want to create a new gift certificate, do I call the model/service validations (like IsValidExpirationDate, etc) directly from the UI layer OR do I hydrate the object first, then pass it in to be validated and then return some sort of validation summary back to the UI?  

Also, if I want to Redeem from the UI layer, do I first call the model/service validation methods from the UI to give user feedback and then call the Redeem method which will run the same checks again internally?


**Example for calling service to do a Redeem operation from UI:**

    string redeemCode = RedeemCodeTextBox.Text;

    GiftCertificateService gcService = new GiftCertificateService();
    GiftCertificate gc = new GiftCertificate(); //do this to call validation methods (should be through service somehow?)

    if (!gc.IsValid(redeemCode))
    {
        //give error back to user
    }

    if (gcService.GetRemainingBalance(redeemCode) &lt; amount)
    {
        //give error back to user
    }

    //if no errors
    gcService.Redeem(code,amount);


**Example for creating a new Gift certificate from UI:**

    GiftCertificateService gcService = new GiftCertificateService();
    GiftCertificate gc = new GiftCertificate();

    if (!gc.IsValidExpDate(inputExpDate))
    {
        //give error to user..
    }

    //if no errors...
    gc.Code = gcService.GetNewCode();
    gc.Amount = 10M;
    gc.ExpirationDate = inputExpDate;
    gcService.SaveNewGC(gc);
    //method updates the gc with the new id...


Something feels wrong about way GCs are being created and how the validations are separated between entity/service.  The user/consumer should not have to be concerned with what validations are in which place... advice?

How does a service layer fit into my repository implementation?

I am about to implement an Entity Framework 6 design with a repository and unit of work.

There are so many articles around and I&#39;m not sure what the best advice is: For example I realy like the pattern implemented here: for the reasons suggested in the article [here][1]

However, `Tom Dykstra (Senior Programming Writer on Microsoft&#39;s Web Platform &amp; Tools Content Team)` suggests it should be done in another article: [here][2]

I subscribe to `Pluralsight`, and it is implemented in a slightly different way pretty much every time it is used in a course so choosing a design is difficult.

Some people seem to suggest that unit of work is already implemented by `DbContext` as in this [post][3], so we shouldn&#39;t need to implement it at all.

I realise that this type of question has been asked before and this may be subjective but my question is direct:

I like the approach in the first (Code Fizzle) article and wanted to know if it is perhaps more maintainable and as easily testable as other approaches and safe to go ahead with?

Any other views are more than welcome.


  [1]: http://codefizzle.wordpress.com/2012/07/26/correct-use-of-repository-and-unit-of-work-patterns-in-asp-net-mvc/
  [2]: http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
  [3]: http://social.msdn.microsoft.com/Forums/en-US/435bf3a3-a358-41cf-a1b0-9f4387dcf5f2/is-unit-of-work-functionality-already-available-inside-the-dbcontext-in-ef-5?forum=adodotnetentityframework

Entity Framework 6 Code First - Is Repository Implementation a Good One?

My repositories deal with and provide persistence for a rich domain model.  I do not want to expose the anemic, Entity Framework data entity to my business layers, so I need some way of mapping between them.

In most cases, constructing a domain model instance from a data entity requires the use of parameterised constructors and methods (since it is rich).  It is not as simple as a property/field match.  AutoMapper could be used for the opposite situation (mapping to data entities) but not when creating domain models.

**Below is the core of my repository pattern.**  

The `EntityFrameworkRepository` class works with two generic types:

 - `TDomainModel`: The rich domain model
 - `TEntityModel`: The Entity Framework data entity

Two abstract methods are defined: 

 - `ToDataEntity(TDomainModel)`: To convert to data entities (for `Add()` and `Update()` methods)
 - `ToDomainModel(TEntityModel)`: To construct domain models (for the `Find()` method).  

Concrete implementations of these methods would define the mapping required for the repository in question.

    public interface IRepository&lt;T&gt; where T : DomainModel
    {
        T Find(int id);
        void Add(T item);
        void Update(T item);
    }

    public abstract class EntityFrameworkRepository&lt;TDomainModel, TEntityModel&gt; : IRepository&lt;TDomainModel&gt;
        where TDomainModel : DomainModel
        where TEntityModel : EntityModel
    {
        public EntityFrameworkRepository(IUnitOfWork unitOfWork)
        {
            // ...
        }

        public virtual TDomainModel Find(int id)
        {
            var entity = context.Set&lt;TEntityModel&gt;().Find(id);

            return ToDomainModel(entity);
        }

        public virtual void Add(TDomainModel item)
        {
            context.Set&lt;TEntityModel&gt;().Add(ToDataEntity(item));
        }

        public virtual void Update(TDomainModel item)
        {
            var entity = ToDataEntity(item);

            DbEntityEntry dbEntityEntry = context.Entry&lt;TEntityModel&gt;(entity);

            if (dbEntityEntry.State == EntityState.Detached)
            {
                context.Set&lt;TEntityModel&gt;().Attach(entity);

                dbEntityEntry.State = EntityState.Modified;
            }
        }

        protected abstract TEntityModel ToDataEntity(TDomainModel domainModel);
        protected abstract TDomainModel ToDomainModel(TEntityModel dataEntity);
    }

**Here is a basic example of a repository implementation:**

    public interface ICompanyRepository : IRepository&lt;Company&gt;
    {
        // Any specific methods could be included here
    }

    public class CompanyRepository : EntityFrameworkRepository&lt;Company, CompanyTableEntity&gt;, ICompanyRepository
    {
        protected CompanyTableEntity ToDataEntity(Company domainModel)
        {
            return new CompanyTable()
            {
                Name = domainModel.Name,
                City = domainModel.City
                IsActive = domainModel.IsActive
            };
        }

        protected Company ToDomainModel(CompanyTableEntity dataEntity) 
        {
            return new Company(dataEntity.Name, dataEntity.IsActive)
            {
                City = dataEntity.City
            }
        }
    }

**Problem:**

A `Company` might be composed of many `Departments`.  If I want to eagerly load these from the `CompanyRepository` when fetching a `Company` then where would I define the mapping between a `Department` and a `DepartmentDataEntity`?

I could provide more mapping methods in the `CompanyRepository`, but this will soon get messy.  There would soon be duplicated mapping methods across the system.

What is a better approach to the above problem?

Repository pattern and mapping between domain models and Entity Framework

In Domain Driven Design, there seems to be [lots][1] of [agreement][2] that Entities should not access Repositories directly. 

Did this come from Eric Evans [Domain Driven Design][3] book, or did it come from elsewhere?
 
Where are there some good explanations for the reasoning behind it?
  
edit: To clarify: I&#39;m not talking about the classic OO practice of separating data access off into a separate layer from the business logic - I&#39;m talking about the specific arrangement whereby in DDD, Entities are not supposed to talk to the data access layer at all (i.e. they are not supposed to hold references to Repository objects)

update: I gave the bounty to BacceSR because his answer seemed closest, but I&#39;m still pretty in the dark about this. If its such an important principle, there should be some good articles about it online somewhere, surely?

update: March 2013, the upvotes on the question imply there&#39;s a lot of interest in this, and even though there&#39;s been lots of answers, I still think there&#39;s room for more if people have ideas about this.

  [1]: http://thinkddd.com/blog/2009/03/02/the-specification-pattern/
  [2]: https://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories/827693#827693
  [3]: http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215

DDD - the rule that Entities can&#39;t access Repositories directly

In OOP Design Patterns, what is the difference between the Repository Pattern and a Service Layer?

I am working on an ASP.NET MVC 3 app, and am trying to understand these design patterns, but my brain is just not getting it...yet!!

Difference between Repository and Service Layer?

What is the difference between the terms Factory, Provider and Service?

Just getting into NHibernate and its Repository pattern (POCO classes, etc).

Difference between a Factory, Provider and a Service?

As i dig deeper in to the DbContext, DbSet and associated interfaces, I am wondering why you would need to implement a separate &quot;Generic&quot; Repository around these implementations?

It looks like DbContext and IDbSet do everything you need and include the &quot;Unit Of Work&quot; inside DbContext.

Am I missing something here or does it seem people enjoy adding another layer of dependency for no reason.

Generic Repository With EF 4.1 what is the point

I have been working with Spring Data JPA repository in my project for some time and I know the below points:

- In the repository interfaces, we can add the methods like `findByCustomerNameAndPhone()` (assuming `customerName` and `phone` are fields in the domain object).
- Then, Spring provides the implementation by implementing the above repository interface methods at runtime (during the application run). 

I am interested on how this has been coded and I have looked at the Spring JPA source code &amp; APIs, but I could not find answers to the questions below: 

1. How is the repository implementation class generated at runtime &amp; methods being implemented and injected? 
2. Does Spring Data JPA use CGlib or any bytecode manipulation libraries to implement the methods and inject dynamically?

Could you please help with the above queries and also provide any supported documentation ?

How are Spring Data repositories actually implemented?

While creating an app in Laravel 4 after reading T. Otwell&#39;s book on good design patterns in Laravel I found myself creating repositories for every table on the application.

I ended up with the following table structure:

 - Students: id, name
 - Courses: id, name, teacher_id
 - Teachers: id, name
 - Assignments: id, name, course_id
 - Scores (acts as a pivot between students and assignments): student_id, assignment_id, scores

I have repository classes with find, create, update and delete methods for all of these tables. Each repository has an Eloquent model which interacts with the database. Relationships are defined in the model per Laravel&#39;s documentation: http://laravel.com/docs/eloquent#relationships.

When creating a new course, all I do is calling the create method on the Course Repository. That course has assignments, so when creating one, I also want to create an entry in the score&#39;s table for each student in the course. I do this through the Assignment Repository. This implies the assignment repository communicates with two Eloquent models, with the Assignment and Student model.

My question is: as this app will probably grow in size and more relationships will be introduced, is it good practice to communicate with different Eloquent models in repositories or should this be done using other repositories instead (I mean calling other repositories from the Assignment repository) or should it be done in the Eloquent models all together?

Also, is it good practice to use the scores table as a pivot between assignments and students or should it be done somewhere else?

Managing relationships in Laravel, adhering to the repository pattern

I&#39;m trying to get my head around how to properly use the repository pattern. The central concept of an Aggregate Root keeps coming up. When searching both the web and Stack Overflow for help with what an aggregate root is, I keep finding discussions about them and dead links to pages that are supposed to contain base definitions.

In the context of the repository pattern, **what is an aggregate root?**

What&#39;s an Aggregate Root?

What is the difference between Data Access Objects (DAO) and Repository patterns? I am developing an application using Enterprise Java Beans (EJB3), Hibernate ORM as infrastructure, and Domain-Driven Design (DDD) and Test-Driven Development (TDD) as design techniques.

What is the difference between DAO and Repository patterns?

I always used Repository pattern but for my latest project I wanted to see if I could perfect the use of it and my implementation of “Unit Of Work”. The more I started digging I started asking myself the question: **&quot;Do I really need it?&quot;**

Now this all starts with a couple of comments on Stackoverflow with a trace to Ayende Rahien&#39;s post on his blog, with 2 specific,

* &lt;a href=&quot;http://ayende.com/blog/3955/repository-is-the-new-singleton&quot;&gt;repository-is-the-new-singleton&lt;/a&gt;
* &lt;a href=&quot;http://ayende.com/blog/153701/ask-ayende-life-without-repositories-are-they-worth-living&quot;&gt;ask-ayende-life-without-repositories-are-they-worth-living&lt;/a&gt;

This could probably be talked about forever and ever and it depends on different applications. Whats I like to know,

1. would this approach be suited for a Entity Framework project?
2. using this approach is the business logic still going in a service layer, or extension methods (as explained below, I know, the extension method is using NHib session)?



**That&#39;s easily done using extension methods. Clean, simple and reusable.**


    public static IEnumerable GetAll(
        this ISession instance, Expression&lt;Func&lt;T, bool&gt;&gt; where) where T : class
    {
        return instance.QueryOver().Where(where).List();
    }

Using this approach and `Ninject` as DI, do I need to make the `Context` a interface and inject that in my controllers?

NOT using repository pattern, use the ORM as is (EF)

I&#39;ve been searching for quite some time for a good solution to the problems presented by the typical Repository pattern (growing list of methods for specialized queries, etc.. see: http://ayende.com/blog/3955/repository-is-the-new-singleton).

I really like the idea of using Command queries, particularly through use of the Specification pattern.  However, my problem with specification is that it only relates to the criteria of simple selections (basically, the where clause), and does not deal with the other issues of queries, such as joining, grouping, subset selection or projection, etc.. basically, all the extra hoops many queries must go through to get the correct set of data. 

(note: I use the term &quot;command&quot; as in the Command pattern, also known as query objects.  I&#39;m not talking about command as in command/query separation where there is a distinction made between queries and commands (update, delete, insert))

So I&#39;m looking for alternatives that encapsulate the entire query, but still flexible enough that you&#39;re not just swapping spaghetti Repositories for an explosion of command classes.

I&#39;ve used, for instance Linqspecs, and while I find some value in being able to assign meaningful names to selection criteria, it&#39;s just not enough.  Perhaps i&#39;m seeking a blended solution that combines multiple approaches.

I am looking for solutions that others may have developed to either address this problem, or address a different problem but still satisfies these requirements.  In the linked article, Ayende suggests using the nHibernate context directly, but I feel that largely complicates your business layer because it now also has to contain query information.

I&#39;ll be offering a bounty on this, as soon as the waiting period elapses.  So please make your solutions bounty worthy, with good explanations and I will select the best solution, and upvote the runners up.

NOTE: I&#39;m looking for something that is ORM based.  Doesn&#39;t have to be EF or nHibernate explicitly, but those are the most common and would fit the best.  If it can be easily adapted to other ORM&#39;s that would be a bonus.  Linq compatible would also be nice.

UPDATE:  I&#39;m really surprised that there aren&#39;t many good suggestions here.  It seems like people are either totally CQRS, or they&#39;re completely in the Repository camp.  Most of my apps are not complex enough to warrant CQRS (something with most CQRS advocates readily say that you should not use it for).  

UPDATE:  There seems to be a little confusion here.  I&#39;m not looking for a new data access technology, but rather a reasonably well designed interface between business and data.

Ideally, what i&#39;m looking for is some kind of cross between Query objects, Specification pattern, and repository.  As I said above, Specification pattern only deals with the where clause aspect, and not the other aspects of the query, such as joins, sub-selects, etc..  Repositories deal with the whole query, but get out of hand after a while.  Query objects also deal with the whole query, but I don&#39;t want to simply replace repositories with explosions of query objects.

Well designed query commands and/or specifications

I saw this code work with LINQ to SQL but when I use Entity Framework, it throws this error:

&gt;LINQ to Entities does not recognize the method &#39;System.Linq.IQueryable&#39;1[MyProject.Models.CommunityFeatures] GetCommunityFeatures()&#39; method, and this method cannot be translated into a store expression.`


The repository code is this:

    public IQueryable&lt;Models.Estate&gt; GetEstates()
    {
        return from e in entity.Estates
               let AllCommFeat = GetCommunityFeatures()
               let AllHomeFeat = GetHomeFeatures()
               select new Models.Estate
                          {
                                    EstateId = e.EstateId,
                                    AllHomeFeatures = new LazyList&lt;HomeFeatures&gt;(AllHomeFeat),
                                    AllCommunityFeatures = new LazyList&lt;CommunityFeatures&gt;(AllCommFeat)
                          };
    }

    public IQueryable&lt;Models.CommunityFeatures&gt; GetCommunityFeatures()
    {
        return from f in entity.CommunityFeatures
               select new CommunityFeatures
                          {
                              Name = f.CommunityFeature1,
                              CommunityFeatureId = f.CommunityFeatureId
                          };
    }

    public IQueryable&lt;Models.HomeFeatures&gt; GetHomeFeatures()
    {
        return from f in entity.HomeFeatures
               select new HomeFeatures()
               {
                   Name = f.HomeFeature1,
                   HomeFeatureId = f.HomeFeatureId
               };
    }


LazyList is a List that extends the power of IQueryable.

Could someone explain why this error occurs?

Method cannot be translated into a store expression

I am wondering how should I be grouping my repositories? Like from the examples I seen on the asp.net mvc and in my books they basically use one repository per database table. But that seems like a lot of repositories leading you to have to call up many repositories later on for mocking and stuff.

So I am guessing I should group them. However I am not sure how to group them.

Right now I made a registration Repository to handle all my registration stuff. However there are like 4 tables I need to update and before I had  3 repositories to do this.

For example one of the tables is a license table. When they register I look at their key and check it to see if exists in the database. Now what happens if I need to check this license key or something else from that table at some other spot other then registration?

One spot could be login(check if the key is not expired). 

So what would I do in this situation? Rewrite the code again(break DRY)? Try to merege these 2 repositories together and hope that none of the methods are needed in some other point of time(like maybe I might have a method that checks if userName is used - maybe I will need that somewhere else).

Also if I merge them together I would either need 2 service layers going to the same repository since I think having all the logic for 2 different parts of a site would be long and I would have to have names like ValidateLogin(), ValdiateRegistrationForm(),ValdiateLoginRetrievePassword() and etc.

Or call the Repository anyways and just have a weird sounding name around?

It just seems hard to make a repository that has a general enough name so you can use it for many spots of your application and still make sense and I don&#39;t think calling another repository in a repository would be a good practice?





How to use the repository pattern correctly?

I&#39;m having a hard time understanding the Repository Pattern.

There are a lot of opinions on that topic like in [Repository pattern done right][1] but also other stuff like [Repository is the new Singleton][2] or again like in [Don&#39;t use DAO use Repository][3] or just take [Spring JPA Data + Hibernate + MySQL + MAVEN][4] where somehow a Repository appears to be the same as a DAO object.

I&#39;m getting tired of reading this stuff since imho this can&#39;t be such a hard thing as it is displayed in a lot of articles.

I see it like this: It appears that what I want is something like this:

             ------------------------------------------------------------------------
             |                            Server                                    |
             ------------------------------------------------------------------------
             |                    |                        |                        |
    Client &lt;-|-&gt; Service Layer  &lt;-|-&gt;  Repository Layer  &lt;-|-&gt; ORM / Database Layer |
             |                    |                        |                        |  
             ------------------------------------------------------------------------

The `Service Layer` takes `*DTO`objects and passes those to the `Repository Layer` that basically is nothing more than &quot;the guy&quot; who knows *how* an entity can be stored.

For example assume you have a composition of some tools (*please note that this is just pseudo code*)

    @Entity
    class ToolSet {
      @Id
      public Long id;
      @OneToOne
      public Tool tool1;
      @OneToOne
      public Tool tool2;
    }

    @Entity
    class Tool {
      @Id
      public Long id;
      @OneToMany
      public ToolDescription toolDescription;
    }

    @Entity
    class ToolDescription {
      @Id
      public Long id;
      @NotNull
      @OneToOne
      public Language language

      public String name;
      public String details;
    }

The thing I&#39;m not getting is the part where I am getting a `ToolSetDTO` object from the client.

As I understood it so far I could write a `ToolSetRepository` with a method `ToolSetRepository.save(ToolSetDTO toolSetDto)` that &quot;*knows how to store*&quot; a `ToolSetDTO`. But almost every tutorial does not pass the `*DTO` but the `Entity` instead.

What&#39;s bothering me here is that if you take my `ToolSet` example from above I&#39;d have to do the following steps:

1. Take `toolSetDto` and check if not `null`
2. For each `tool*Dto` owned by `toolSetDto` &lt;br/&gt;a) If has a valid id then convert from `DTO` to `Entity` otherwise create a new database entry &lt;br/&gt; b) `toolDescriptionDto` and convert/save it to the database or create a new entry
3. After checking those above instanciate `ToolSet` (entity) and set it up for persisting it in the database

All this is too complex to simply let the service function (interface for the client) handle this. 

What I was thinking about was creating e.g. a `ToolSetRepository` but the question here is

- Does it take a `ToolSet` entity object or does it use a `DTO` object?
- In any case: Is the `*Repository` allowed to *use* other repository objects? Like when I want to save `ToolSet` but I have to store `Tool` and `ToolDescription` first - would I use `ToolRepository` and `ToolDescriptionRepository` inside `ToolSetRepository`? &lt;br/&gt; If so: Why doesn&#39;t it break the Repository Pattern? If this pattern is basically a layer between the service and my ORM framework it just does not &quot;feel right&quot; to add dependencies to other `*Repository` classes due to dependency reasons. 

I don&#39;t know why I can&#39;t get my head around this. It does not sound *that* complicated but there&#39;s still help out there like `Spring Data`. Another thing that is bothering me since I really don&#39;t see how this makes *anything* easier. Especially since I&#39;m using Hibernate already - I don&#39;t see the benefit (but maybe that&#39;s another question).

So .. I know this is a long question but I put already a few days of research into it. There&#39;s already existing code I am working on right now that starts to become a mess because I just can&#39;t see through this pattern.

I hope somebody can give me a bigger picture than most of the articles and tutorials which do not get beyond implementing a very, very simple example of a Repository Pattern.

  [1]: http://www.codeproject.com/Articles/526874/Repositorypluspattern-cplusdoneplusright
  [2]: http://ayende.com/blog/3955/repository-is-the-new-singleton
  [3]: http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/
  [4]: http://fruzenshtein.com/spring-jpa-data-hibernate-mysql/

Repository Pattern - How to understand it and how does it work with &quot;complex&quot; entities?

I am using the Generic Repository pattern on top of Entity Framework Code First. Everything was working fine until I needed to include more entities in a query. I got to include one entity successfully, but now I can&#39;t figure out how to include multiple entities. Check out what I&#39;ve got so far:

    public IQueryable&lt;TEntity&gt; GetQuery&lt;TEntity&gt;() where TEntity : class
    {
        var entityName = GetEntityName&lt;TEntity&gt;();
        return _objectContext.CreateQuery&lt;TEntity&gt;(entityName);
    }
    
    public IList&lt;TEntity&gt; GetQueryWithInclude&lt;TEntity&gt;(string toInclude) where TEntity : class
    {
        var entityName = GetEntityName&lt;TEntity&gt;();
        return _objectContext.CreateQuery&lt;TEntity&gt;(entityName).Include(toInclude).ToList();
    }
    
    private string GetEntityName&lt;TEntity&gt;() where TEntity : class
    {
        return string.Format(&quot;{0}.{1}&quot;, _objectContext.DefaultContainerName, _pluralizer.Pluralize(typeof(TEntity).Name));
    }

What I tried to do but didn&#39;t work was pass in an array of strings into a function, then try to &quot;append&quot; the includes on top of the query. I was wondering what if I called the GetQueryWithInclude and passed an entity name (actually a navigation property) at a time to aggregate the results of the query, but I&#39;m worried this might duplicate the results of the query on each call... What do you think would be the best way to get this to work?

Thanks in advance!

**UPDATE:**

Here&#39;s an example of what I&#39;m trying to achieve:


    public IQueryable GetQueryWithIncludes(string[] otherEntities)
    {
        var entityName = GetEntityName&lt;TEntity&gt;();
        //now loop over the otherEntities array 
        //and append Include extensions to the query
        //so inside the loop, something like: 
        _objectContext.GetQuery&lt;TEntity&gt;(entityName).Include(otherEntities[index]);
    }

EF Including Other Entities (Generic Repository pattern)

I am trying to learn domain-driven design (DDD), and I think I got the basic idea. But there is something confusing me.

In DDD, are the persistence model and domain model different things? I mean, we design our domain and classes with only domain concerns in mind; that&#39;s okay. But after that when we are building our repositories or any other data persistence system, should we create another representation of our model to use in persistence layer?

I was thinking our domain model is used in persistence too, meaning our repositories return our domain objects from queries. But today, I read this post, and I&#39;m a little confused:

*[Just Stop It! The Domain Model Is Not The Persistence Model][1]*

If that&#39;s true what would be the advantage of having separate persistence objects from domain objects?

  [1]: https://blog.sapiensworks.com/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx


DDD - Persistence Model and Domain Model

Using EF5 with a generic Repository Pattern and ninject for dependency injenction and running into an issue when trying to update an entity to the database utilizing stored procs with my edmx.  

my update in DbContextRepository.cs is:

    public override void Update(T entity)
    {
        if (entity == null)
            throw new ArgumentException(&quot;Cannot add a null entity.&quot;);

        var entry = _context.Entry&lt;T&gt;(entity);

        if (entry.State == EntityState.Detached)
        {
            _context.Set&lt;T&gt;().Attach(entity);
            entry.State = EntityState.Modified;
        }
    }


From my AddressService.cs which goes back to my repository I have:

     public int Save(vw_address address)
    {
        if (address.address_pk == 0)
        {
            _repo.Insert(address);
        }
        else
        {
            _repo.Update(address);
        }

        _repo.SaveChanges();

        return address.address_pk;
    }

When it hits the Attach and EntityState.Modified it pukes with the error:

**An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key.**

I have looked through many of the suggestions in stack and on the Internet and not coming up with anything that resolves it.  Any work arounds would be appreciated.

Thanks!

An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key

I know that this question was asked so many times, but none of answers helped me.

I&#39;m getting exception in Laravel 5

    BindingResolutionException in Container.php line 785:
    Target [App\Contracts\CustomModelInterface] is not instantiable.

What I&#39;ve done without success:

 - Register `App\Providers\AppRepositoryProvider` in `app.php` providers
 - `php artisan clear-compiled`
 - Everything works if I replace interfaces on repositories in MyService, but I feel that it&#39;s wrong (should it be handled by IoC container?).

Structure:

    app
      - Contracts
        - CustomModelInterface.php
      - Models
        - CustomModel.php
      - Repositories
        - CustomModelRepository.php
      - Providers
        - AppRepositoryProvider.php
      - Services
        - MyService.php

App\Contracts\CustomModelInterface.php

    &lt;?php namespace App\Contracts;
    
    interface CustomModelInterface {
    	public function get();
    }

App\Repositories\CustomModelRepository.php

    &lt;?php namespace App\Repositories;
    
    use App\Contracts\CustomModelInterface;
    use App\Models\CustomModel;
    
    class CustomModelRepository implements CustomModelInterface {
    	
    	private $Model;
    	
    	public function __construct(CustomModel $model) {
    		$this-&gt;Model = $model;
    	}
    
    	public function get() {
    		return &#39;result&#39;;
    	}
    }

App\Services\MyService.php (Keep business logic / layer between controller and repositories)

    &lt;?php namespace App\Services;
    
    use App\Contracts\CustomModelInterface;
    
    class MyService {
    
    	private $Model;
    	
    	public function __construct(CustomModelInterface $customModel) {
    		$this-&gt;Model= $customModel;
    	}
    
    	public function getAll() {
    		return $this-&gt;Model-&gt;get();
    	}
    }

App\Providers\AppRepositoryProvider.php

    &lt;?php namespace App\Providers;
    
    use Illuminate\Support\ServiceProvider;
    
    class AppRepositoryProvider extends ServiceProvider {
    
    	public function boot() {}
    
    	public function register() {
    		$models = array(
    			&#39;CustomModel&#39;
    		);
    		
    		foreach ($models as $idx =&gt; $model) {
    			$this-&gt;app-&gt;bind(&quot;App\Contracts\{$model}Interface&quot;, &quot;App\Repositories\{$model}Repository&quot;);
    		}
    	}
    }

My controller looks like:

    &lt;?php namespace App\Http\Controllers;
    
    use App\Services\MyService;
    
    class SuperController extends Controller {
    	
    	private $My;
    
    	public function __construct(MyService $myService) {
    		$this-&gt;My = $myService;
    	}
    
    	public function getDetails() {
    		return $this-&gt;My-&gt;getAll();
    	}
    }

composer.json

    &quot;autoload&quot;: {
    		&quot;classmap&quot;: [
    			&quot;database&quot;
    		],
    		&quot;psr-4&quot;: {
    			&quot;App\\&quot;: &quot;app/&quot;,
    			&quot;App\\Models\\&quot;: &quot;app/Models/&quot;,
                &quot;App\\Contracts\\&quot;: &quot;app/Contracts/&quot;,
                &quot;App\\Repositories\\&quot;: &quot;app/Repositories/&quot;
    		}
    	},


  [1]: http://stackoverflow.com/a/29690949/1179550

Laravel 5 - Interface is not instantiable

Currently, I am trying to use Dapper ORM with Unit Of Work + Repository Pattern.

I want to use Unit of Work as opposed to a simple dapper Repository due to the fact that my insert and updates require a degree of transaction processing. I have been unable to find any useful examples as most seem to use Entity Framework and have leakage issue within the Unit of Work.

Could someone please point me in the right direction?

How to implement Unit Of Work pattern with Dapper?

I am learning repository pattern and was reading [Repository Pattern with Entity Framework 4.1 and Code First
][1] and [Generic Repository Pattern - Entity Framework, ASP.NET MVC and Unit Testing Triangle
][2] about how they implement the repository pattern with Entity Framework.

Saying 

&gt; •Hide EF from upper layer  
•Make code better testable

Make code better testable I do understand, but why hide EF from upper layer?

Looking at their implementation, it seems just wrap the entity framework with a generic method for query the entity framework.  Actually what&#39;s the reason for doing this?

I am assuming is for 

 1. Loose coupling (that&#39;s why hide EF from upper layer?) 
 2. Avoid repeat writting same LINQ statement for same query

Am I understand this correctly?  

If I write a DataAccessLayer which is a class have methods

    QueryFooObject(int id)
    {
    ..//query foo from entity framework
    } 
    
    AddFooObject(Foo obj)
    {
    .. //add foo to entity framework
    }
    ......
    QueryBarObject(int id)
    {
    ..
    }
    
    AddBarObject(Bar obj)
    {
    ...
    }

Is that also a Repository Pattern?

Explaination for dummy will be great :)

  [1]: http://www.codeproject.com/Tips/309753/Repository-Pattern-with-Entity-Framework-4-1-and-C
  [2]: http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle

Why use Repository Pattern or please explain it to me?

I recently learned ASP.NET MVC (I love it). I&#39;m working with a company that uses dependency injection to load a Repository instance in each request, and I&#39;m familiar with using that repository.

But now I&#39;m writing a couple of MVC applications of my own. I don&#39;t fully understand the hows and whys of the repository my company uses, and I&#39;m trying to decide the best approach to implement data access.

I am using C# and Entity Framework (with all the latest versions).

I see three general approaches for handling data access.

1. Regular DB context within a using statement each time I access data. This is simple and it works okay. However, if two locations need to read the same data within one request, the data must be read twice. (With a single repository per request, the same instance would be used in both places and I understand the second read would simply return the data from the first read.)

2. A typical [repository pattern](http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application). For reasons I don&#39;t understand, this typical pattern involves creating a wrapper class for every table used from the database. That seems wrong to me. In fact, since they are implemented also as interfaces, I&#39;d technically be creating two wrapper classes for each table. EF creates tables for me. I don&#39;t believe this approach makes sense.

3. There is also a [generic repository pattern](http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle) where a single repository class is created to serve all entity objects. This makes much more sense to me. But does it make sense to others? Is the link above the best approach?

I&#39;d love to get some input from others on this topic. Are you writing your own repository, using one of those above, or doing something different altogether. Please share.





Best Repository Pattern for ASP.NET MVC

Combining `Unit of Work` and `Repository Pattern` is something used fairly widely nowadays. As Martin Fowler [says][1] a purpose of using `UoW` is to form a **Business Transaction** while being ignorant of how repositories actually work (being persistent ignorant). I&#39;ve reviewed many implementations; and ignoring specific details (concrete/abstract class, interface,...) they are more or less similar to what follows:

    public class RepositoryBase&lt;T&gt;
    {
        private UoW _uow;
        public RepositoryBase(UoW uow) // injecting UoW instance via constructor
        {
           _uow = uow;
        }
        public void Add(T entity)
        {
           // Add logic here
        }
        // +other CRUD methods
    }
        
    public class UoW
    {
        // Holding one repository per domain entity

        public RepositoryBase&lt;Order&gt; OrderRep { get; set; }
        public RepositoryBase&lt;Customer&gt; CustomerRep { get; set; }
        // +other repositories
        
        public void Commit()
        {
           // Psedudo code: 
           For all the contained repositories do:
               store repository changes.
        }
    }

**Now my problem:**

`UoW` exposes public method **`Commit`** to store the changes. Also, because each repository has a shared instance of `UoW`, each `Repository` can access method `Commit` on UoW. Calling it by one repository makes all other repositories store their changes too; hence the result the whole concept of transaction collapses:

    class Repository&lt;T&gt; : RepositoryBase&lt;T&gt;
    {
        private UoW _uow;
        public void SomeMethod()
        {
            // some processing or data manipulations here
            _uow.Commit(); // makes other repositories also save their changes
        }
    }

I think this must be not allowed. Considering the purpose of the `UoW` (business transaction), the method `Commit` should be exposed only to the one who started a **Business Transaction** for example Business Layer. What surprised me is that I couldn&#39;t find any article addressing this issue. In all of them `Commit` can be called by any repo being injected.

**PS:** I know I can tell my developers not to call `Commit` in a `Repository` but a trusted Architecture is more reliable than trusted developers!


  [1]: http://martinfowler.com/eaaCatalog/unitOfWork.html

Unit of Work + Repository Pattern: The Fall of the Business Transaction Concept

*Preface: I&#39;m attempting to use the repository pattern in an MVC architecture with relational databases.*

I&#39;ve recently started learning TDD in PHP, and I&#39;m realizing that my database is coupled much too closely with the rest of my application. I&#39;ve read about repositories and using an [IoC container][1] to &quot;inject&quot; it into my controllers. Very cool stuff. But now have some practical questions about repository design. Consider the follow example.

&lt;!-- language: lang-php --&gt;

    &lt;?php

    class DbUserRepository implements UserRepositoryInterface
    {
        protected $db;

        public function __construct($db)
        {
            $this-&gt;db = $db;
        }

        public function findAll()
        {
        }

        public function findById($id)
        {
        }

        public function findByName($name)
        {
        }

        public function create($user)
        {
        }

        public function remove($user)
        {
        }

        public function update($user)
        {
        }
    }


## Issue #1: Too many fields

All of these find methods use a select all fields (`SELECT *`) approach. However, in my apps, I&#39;m always trying to limit the number of fields I get, as this often adds overhead and slows things down. For those using this pattern, how do you deal with this?

## Issue #2: Too many methods

While this class looks nice right now, I know that in a real-world app I need a lot more methods. For example:

- findAllByNameAndStatus
- findAllInCountry
- findAllWithEmailAddressSet
- findAllByAgeAndGender
- findAllByAgeAndGenderOrderByAge
- Etc.

As you can see, there could be a very, very long list of possible methods. And then if you add in the field selection issue above, the problem worsens. In the past I&#39;d normally just put all this logic right in my controller:

&lt;!-- language: lang-php --&gt;

    &lt;?php
    
    class MyController
    {
        public function users()
        {
            $users = User::select(&#39;name, email, status&#39;)
                -&gt;byCountry(&#39;Canada&#39;)-&gt;orderBy(&#39;name&#39;)-&gt;rows();
    
            return View::make(&#39;users&#39;, array(&#39;users&#39; =&gt; $users));
        }
    }

With my repository approach, I don&#39;t want to end up with this:

&lt;!-- language: lang-php --&gt;

    &lt;?php

    class MyController
    {
        public function users()
        {
            $users = $this-&gt;repo-&gt;get_first_name_last_name_email_username_status_by_country_order_by_name(&#39;Canada&#39;);

            return View::make(&#39;users&#39;, array(&#39;users&#39; =&gt; $users))
        }

    }

## Issue #3: Impossible to match an interface

I see the benefit in using interfaces for repositories, so I can swap out my implementation (for testing purposes or other). My understanding of interfaces is that they define a contract that an implementation must follow. This is great until you start adding additional methods to your repositories like `findAllInCountry()`. Now I need to update my interface to also have this method, otherwise, other implementations may not have it, and that could break my application. By this feels insane...a case of the tail wagging the dog.

### Specification Pattern?
This leads me to believe that repository should only have a fixed number of methods (like `save()`, `remove()`, `find()`, `findAll()`, etc). But then how do I run specific lookups? I&#39;ve heard of the [Specification Pattern][2], but it seems to me that this only reduces an entire set of records (via `IsSatisfiedBy()`), which clearly has major performance issues if you&#39;re pulling from a database.

## Help?

Clearly, I need to rethink things a little when working with repositories. Can anyone enlighten on how this is best handled?

  [1]: http://laravel.com/docs/4.2/ioc
  [2]: http://en.wikipedia.org/wiki/Specification_pattern

Proper Repository Pattern Design in PHP?

I see two main &quot;schools of thoughts&quot; when it comes to creating larger-scale enterprise-wide apps on .NET (Winforms, WPF, ASP.NET).

Some folks use the &quot;repository pattern&quot; which uses a repository that knows how to fetch, insert, update and delete objects. Those objects are rather &quot;dumb&quot; in that they don&#39;t necessarily contain a whole lot of logic - e.g. they&#39;re more or less data-transfer objects.

The other camp uses what I call &quot;smart&quot; business objects that know how to load themselves, and they typically have a Save(), possibly Update() or even Delete() method. Here you really don&#39;t need any repository - the objects themselves know how to load and save themselves.

**Big question is**: which do you use or prefer? And why? 

Do you use the same approach in all your apps, or do you have any particular criteria when to choose one approach over the other? If so - what are those criteria?

I&#39;m not trying to start a flame-war here - just trying to find out what everyone thinks about this and what your opinion is, and why you use one (or both) patterns over the other.

Thanks for any constructive input!

All Repository Pattern Solutions on Gang of Coders

Total of 27 Repository Pattern Solutions