接口由Moq用于生成模拟对象进行单元测试.但这是接口重新使用的唯一时间.
我们系统中没有具体对象实现多个接口.
有谁能告诉我这是否会导致问题呢？如果是这样,他们会是什么？
我在想,我们的应用程序有很多重复,例如在这两个接口(在我们的服务层中编辑)：唯一不同的是方法名和参数的类型,但语义上它们是与他们发送消息的存储库相同的事情：
interface ICustomer
{
void AddCustomer(Customer toAdd);
void UpdateCustomer(Customer toUpdate);
Customer GetById(int customerId);
}
interface IEmployee
{
void AddEmployee(Employee toBeAdded);
void UpdateEmployee(Employee toUpdate);
Employee GetById(int employeeId);
}
这就是我认为重用抽象原则会进入的地方,即将代码转换成如下代码：
public interface IEmployee: IAdd<Employee>,IUpdate<Employee>,IFinder<Employee>
这不是关于存储库模式 – 这是关于任何层中的接口,看起来像它们共享语义相同的行为.是否值得为这些操作导出通用接口,并使“子接口”从它们继承？
至少它会保持方法的签名一致.但这会给我什么其他好处？ (Liskov替代原则)
解决方法
public interface IRepository<TEntity> where TEntity : IEntity
{
T FindById(string Id);
T Create(T t);
bool Update(T t);
bool Delete(T t);
}
public interface IEntity
{
string Id { get; set; }
}
编辑
No concrete objects in our system implement multiple interfaces.
Can anyone tell me if this is going to cause problems down the road?
And if so,what would they be?
是的,如果还没有开始这样做会造成问题.
你会得到一堆不会为你的解决方案添加的接口,在维护和创建它们的时候耗尽了很大一部分时间.随着你的代码库的大小增加,你会发现并不是一切都像你曾经想过的一样
请记住,接口只是一种工具,是实现抽象级别的工具.而抽象是一个概念,一个模式,一个独立实体共享的原型.
你总结了这个,
This isn’t about the repository pattern – this is about interfaces in any layer that look like they share semantically identical behavIoUrs. Is it worth deriving common interfaces for these operations and making “sub-interfaces” inherit from them?
这不是关于接口,这是关于抽象的,Repository模式演示了如何抽象出针对特定对象定制的行为.
上面给出的示例没有任何名为AddEmployee或UpdateEmployee的方法…这样的方法只是浅层接口,而不是抽象.
存储库模式的概念是显而易见的,因为它定义了一组行为,这些行为由多个不同的类实现,每个类针对特定实体进行定制.
考虑到为每个实体(UserRepository,BlogRepository等)实现Repository,并且考虑到每个存储库必须支持核心功能集(基本CRUD操作),我们可以采用该核心功能集并在界面中定义它,然后在每个Repository中实现这个界面.
现在我们可以从我们从Repository模式中学到的东西,并将其应用到我们应用程序的其他部分,从而定义一个新的接口中的一些对象所共享的核心行为,然后从接口.
public interface IVehicleOperator<TVehicle> where TVehicle : IVehicle
{
void Accelerate();
void Brake();
}
在这样做的时候,我们不再有1：1的映射,而是一个实际的抽象.
在我们讨论这个话题的时候,也许值得一看的是装饰图案.
