2

我有一个定义了属性和方法的客户类。目前它包含与客户相关的任何类型任务的方法。例如，它包含一个方法“InsertOrUpdateCustomer”。此方法要么将新客户记录插入数据库，要么便于编辑现有客户记录。

该类还包含一些客户字段的验证方法。

我认为这不是更好的方法。我想像这样打破它：

interface ICustomer
{
    string CustomerName;
    date FinancialYearStartDate;
    date FinancialYearEndDate;
    string TaxNo;
    string Address;
}

我想将此接口实现到另一个类，比如客户：

class Customers: ICustomer
{
    // Properties
    CustomerName { get; set; }
    FinancialYearStartDate { get; set; }
    FinancialYearEndDate  { get; set; }
    TaxNo { get; set; }
    Address { get; set; }

    // Constructor
}

我想知道：

  1. 在哪里添加插入或更新新客户的方法？我应该创建另一个类还是向上面的类添加方法？

  2. 用上述给定的方式打破我的旧单班是否有益？接口在上面的代码中有什么好处？

  3. 我想删除验证方法并改用验证框架。我是否需要创建一个不同的类“CustomerValidations”来进行验证，或者我应该使用上面的类本身？

4

4 回答 4

4
  1. 对于插入和更新方法，我会使用 CRUD 方法（例如）创建一个存储库ICustomerRepository
  2. 我没有看到 ICustomer 界面的直接好处
  3. 我会使用验证在业务实体之外的方法；例如，在专用验证类中，或在spring.net 验证等配置文件中。

总的来说，我认为每个类都有一个单一的职责是一个好主意——例如业务状态Customer、持久存储NHibernateCustomerRepository : ICustomerRepository和验证CustomerValidator。

存储库的示例：

interface ICustomerRepository
{
  // Get by id
  Customer Get(int id);
  void Delete(Customer customer);
  IList<Customer> GetAll();
  // creates a new instance in datastore
  // returns the persistent identifier
  int Save(Customer customer);
  // updates if customer exists,
  // creates if not
  // returns persistent identifier
  int SaveOrUpdate(Customer customer);
  // updates customer
  void Update(Customer customer);

  // specific queries
  IList<Customer> GetAllWithinFiscalYear(DateTime year);
  // ...
}

如您所见，该接口的第一个方法对于大多数业务实体来说是相似的，可以抽象为：

interface IRepository<TId, TEntity>
{
  // Get by id
  TEntity Get(TId id);
  void Delete(TEntity entity);
  IList<TEntity> GetAll();
  // creates a new instance in datastore
  // returns the persistent identifier
  TId Save(TEntity entity);
  // updates if customer exists,
  // creates if not
  // returns persistent identiefier
  TId SaveOrUpdate(TEntity entity);
  // updates customer
  void Update(TEntity entity);
}

interface ICustomerRepository : IRepository<int, Customer>
{
  // specific queries
  IList<Customer> GetAllWithinFiscalYear(DateTime year);
}
于 2010-11-26T08:39:55.660 回答
2

我的回答：

  1. 我会将 Insert 方法放在包含 ICustomers 的类中（我想会有一个或多个）。至于更新，就看这个方法做什么了。如果您要更新一些客户的内部字段/属性，它应该与 ICustomers 一起使用；

  2. 恕我直言，最大的好处之一是对依赖于客户的代码进行单元测试要容易得多，因为您可以轻松地模拟/存根它。

  3. 我会使用课程本身。

于 2010-11-26T08:35:54.310 回答
1

诸如“ InsertOrUpdateCustomer”之类的操作通常是客户实体服务的一部分（在适配器模型中）（即在另一个类中，如您所建议的）

思考的方式是：“拯救客户是谁的责任？”

一种可能性是将 a “注入”ICustomerValidator到 Save 方法中。

于 2010-11-26T08:35:11.283 回答
0

为本质上是数据容器的类引入接口很少有好处。相反，您可能希望分别创建两个具有数据库持久性和验证角色的类。有一个接口可能让您有机会让这些类可互换以进行测试或不同的存储/验证策略。

于 2010-11-26T08:38:33.783 回答