CODEWITHSUNDEEP
c#entity-frameworkrepository-patterndata-access-layer
Jeroen1984
Jeroen1984

Reputation: 1686

Entity Framework Repository Pattern in DAL, how to implement Update functions?

or one of our projects (a C# Windows Service, mainly for processing data from external resources and read/write this data to a SQL Server database) we have implemented the Repository Pattern in the DAL, and we created a repository class for each POCO object (which represents a table row). The use of these Repository classes is managed by a Unit of Work pattern, so all Repositories share the same DbContext within a single unit of work, but maybe that's irrelevant to the quesion.

The repository class for, let's say a Customer entity, is implemented as following:

public class CustomerRepository
{
    private readonly MyContext _context;
    public CustomerRepository(MyContext context)
    {
        _context = context;
    }

    public Customer GetCustomer(string id)
    {
        return _context.Customers.Find(new object[] {id});
    }

    public IEnumerable<Customer> GetAllCustomers(Func<Customer,bool> predicate )
    {
        return _context.Customers.Where(predicate);
    }
    public IEnumerable<Customer> GetCustomerByCity(string city)
    {
        return _context.Customers.Where(c=>s.City.Equals(city));
    }


    public void SetAge(string id, byte age)
    {
         _context.Customers.Find(new object[] { id }).Age = age;
    }

    public void Update(Customer customer)
    {
        _context.Entry(customer).State = EntityState.Modified;
    }

}

Now i have a few questions about what is best practice for the update-methods:

The update operations are mostly limited to a single field in a single row.

Maybe anyone would like to share some real-world thoughts with me?

Upvotes: 2

Views: 3385

Answers (3)

Scottie
Scottie

Reputation: 11308

Some argue that EF IS the unit of work and repository and that you should let it do the work for you. I'm slowly coming around to this way of thinking. EF is really good at managing all of this, and it's pointless to re-write tools that already exist.

Something to think about...

Upvotes: 4

phil soady
phil soady

Reputation: 11328

Im inclined to agree with Daryal. But would emphasise you dont quiet have the class repository model right. Ideally You Want the Repository to be generic. Operate on Full objects and provide DAL services.

 public class DAL.Repository<poco> {

    //methods for CRUD, get List, search whatever you see as right
    // eg ...add error handling....
    void add(poco p){
       context.attach(p);
    ... 
 }


//  The domain/core model layer would have much of the object based business logic
 public class CORE.PocoXYZ {
    //all the get sets and methods required to manipulate the object
 }


// And your Unit of Work Class
Public class DAL.UoW{
    context.savechanges();
}


So i would suggest you perform object level Data storage in the DAL. But do all teh object manipulation in the core.  The DAL would control the save in a UoW class that managed all Repositories.

A service or UI layer might inject the UoW/Repository layer into the Core layer.

Upvotes: 2

daryal
daryal

Reputation: 14919

  • Is it recomended to have separate methods for updating specific fields in de database, like the SetAge() method?

I do not think it will be wise to have seperate operations for each property. You will endup with methods encapsulating properties. Also, instead of implementing methods for each type, why not creating a base repository to implement commmon operations? Instead of GetAllCustomers you may implement GetAll in a base class and derive all your repositories from this base repository.

  • Or Is it recommended to get the Customer object to our BLL (with GetCustomer(id)), and just set the properties in the BLL like customer.Age = 35;, and then save this changes?

I think the problem is not where you change the properties, the problem is the anemic domain model. You have a seperate business layer, which modifies objects using repository methods. This violates the object orienteed approach which dictates objects shall have both properties and methods.

Upvotes: 1

Related Questions