Шаблон репозитория Framework Entity Framework в DAL, как реализовать функции обновления?

Question

или один из наших проектов (C# Windows Service, в основном для обработки данных из внешних ресурсов и чтения/записи этих данных в базу данных SQL Server), мы реализовали шаблон хранилища в DAL, и мы создали класс репозитория для каждого POCO (который представляет собой таблицу). Использование этих классов репозитория управляется шаблоном Unit of Work, поэтому все репозитории совместно используют один и тот же DbContext в одной единице работы, но, возможно, это не имеет отношения к вопросу.

Репозиторий класс для, скажем, объект клиента, осуществляется следующим образом:

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; 
    } 

} 

Теперь у меня есть несколько вопросов о том, что лучшая практика для обновления-методов:

• Рекомендуется ли иметь отдельные методы для обновления определенных полей в базе данных, например метода SetAge()?
• Или Рекомендуется получить объект Customer для нашего BLL (с ​​GetCustomer (id)) и просто установить свойства в BLL как customer.Age = 35 ;, а затем сохранить эти изменения?

Операции обновления в основном ограничиваются одним полем в одной строке.

Может быть, кто-нибудь хотел бы поделиться с нами некоторыми реальными мыслями?

Answer 1

• Рекомендуется ли использовать отдельные методы для обновления определенных полей в базе данных, например метод SetAge()?

Я не думаю, что было бы разумно иметь отдельные операции для каждого объекта. Вы получите методы инкапсуляции свойств. Кроме того, вместо того, чтобы внедрять методы для каждого типа, почему бы не создать базовый репозиторий для выполнения операций с commmon? Вместо GetAllCustomers вы можете реализовать GetAll в базовом классе и получить все ваши репозитории из этого базового хранилища.

• Или это рекомендуется, чтобы получить объект клиента к нашему УСК (с GetCustomer (ID)), а просто установить свойства в УСК как customer.Age = 35 ;, а затем сохранить эти изменения?

Я думаю, что проблема не в том, где вы меняете свойства, проблема в том, что anemic domain model. У вас есть отдельный бизнес-уровень, который изменяет объекты с использованием методов репозитория. Это нарушает ориентированный на объект подход, который диктует, что объекты должны иметь как свойства, так и методы.

Answer 2

Я склонен согласиться с Дарьялом. Но подчеркнуть, что у вас нет спокойной модели класса репозитория. В идеале вы хотите, чтобы репозиторий был общим. Работайте над объектами Full и предоставляйте службы DAL.

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. 

Сервис или слой пользовательского интерфейса может вводить слой UoW/Repository в слой Core.

Answer 3

Некоторые утверждают, что EF является единицей работы и хранилища и что вы должны позволить ей выполнять эту работу за вас. Я медленно приближаюсь к этому способу мышления. EF действительно хорош в управлении всем этим, и бессмысленно переписывать уже существующие инструменты.

Что-то думать о ...