具有继承类的 IRepository
为了与数据输入的存储库模式保持一致，我有一个关于使用继承类的问题。例如，假设我要上课...
class Employee
IEmployeeRepository
{
Add(Employee employee);
}
这工作正常，到目前为止没有任何问题...但现在让我们说我继续...
class Manager : Employee
好吧，现在让我们假设我永远不需要输入与经理不同的经理员工？这里最好的方法是什么？诸如 .. 之类的场景
IEmployeeRepository
{
Add<T>(T employee) where T : Employee
}
是否是最好的方法，或者我是否需要为每种类型抽象一个不同的存储库？
In keeping with the Repository pattern of data input, I've a question in regards to using inherited classes. For instance, suppose I would have the class...
class Employee
IEmployeeRepository
{
Add(Employee employee);
}
This works fine, nothing wrong with it so far... but now let's say I continue on..
class Manager : Employee
Okay, now let's assume that I never need to enter a manager different than an Employee? What's the best approach here? Would a scenario such as ..
IEmployeeRepository
{
Add<T>(T employee) where T : Employee
}
Be the best approach, or do I need to abstract a different repository for each type?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果他们都是员工，我可能会创建一个界面并将其限制于此。例如：
If they are all employees, I would probably create an interface and constrain it to that. For example:
如果事情的处理方式不同，那么您应该为新类型创建另一个存储库。
如果两者从来没有不同的逻辑（并且他们确实不应该考虑经理在您的情况下仍然是员工），那么您可以重新使用您已有的内容。您甚至不需要更改代码（只要 Manager 继承自 Employee 类）：
应该可以正常工作。
If things are being handled differently, then you should create another Repository for the new type.
If the two never have different logic (and they really shouldn't considering a Manager is still an Employee in your case), then you can re-use what you already have. You shouldn't even need to change the code (as long as Manager inherits from the Employee class):
Should work just fine.
所以你没有抽象。您只有一个
Employee，并且您需要一个存储库。是的，如果您有几个子类的抽象。要点是通常不需要仅用于子类的抽象类的存储库。
So you do not have an abstraction. You only have an
Employeeand you need a repository for that.Yes if you have an abstraction of a few subclasses. The point is you normally do not need a repository for abstract classes only for subclasses.