或我们的一个项目(C #Windows服务,主要用于处理来自外部资源的数据以及将此数据读/写到SQL Server数据库)我们在DAL中实现了存储库模式,并且我们创建了一个存储库类每个POCO对象(表示一个表行)。这些存储库类的使用由工作单元模式管理,因此所有存储库在单个工作单元内共享相同的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;
}
}
现在我有一些关于更新方法的最佳实践的问题:
更新操作主要限于单行中的单个字段。
也许有人愿意与我分享一些现实世界的想法?
答案 0 :(得分:4)
有些人认为EF是工作单元和存储库,你应该让它为你工作。我正慢慢地想到这种思维方式。 EF非常善于管理所有这些,重写已经存在的工具毫无意义。
要考虑的事情......
答案 1 :(得分:2)
我倾向于同意Daryal。但是会强调你不要安静地拥有类存储库模型。理想情况下,您希望存储库是通用的。在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.
服务或UI层可能会将UoW / Repository层注入Core层。
答案 2 :(得分:1)
我认为对每个房产进行单独操作并不明智。您将最终使用封装属性的方法。此外,为什么不创建基本存储库来实现commmon操作,而不是为每种类型实现方法?您可以在基类中实现GetAllCustomers
而不是GetAll
,而是从此基本存储库中派生所有存储库。
我认为问题不是你改变属性的地方,问题是anemic domain model。您有一个单独的业务层,它使用存储库方法修改对象。这违反了对象的方法,该方法规定对象应具有属性和方法。