【发布时间】：2010-12-24 13:59:14
【问题描述】：
问题
- 数据访问层 (DAL) 和业务逻辑层 (BLL) 应该通过接口还是通过抽象基类公开？
- 什么时候应该选择抽象类而不是接口，什么时候应该选择接口而不是抽象类？
- 使用抽象基类的一个好处是，如果外部方决定使用基抽象类扩展/自定义（特定层的）功能，那么该特定层公开的许多方法将已经在基中实现抽象类，而使用接口则需要实现特定层公开的所有公共方法？
【问题讨论】：
标签： .net design-patterns oop
【发布时间】：2010-12-24 13:59:14
【问题描述】：
主要区别在于类只能从一个 cingle 类继承，而您可以实现多个接口。
有一个很好的discussion of the pros and cons here。
1) 通常，这些是具体的类 - 它们可能使用接口/抽象类来形成一致的框架（BusinessBase 类、BusinessCommand 类等），但我不确定您的意思。
2) 当您想要继承某些实现时，通常使用抽象类。当您不想限制应用程序类从其他事物继承时，通常是一个接口。
3) 是的，这是主要优点，但由于单一继承模型存在缺点。
【讨论】：
-
1) ROUX - “……但我不确定你在说什么。”假设 DAL 层暴露了 10 个方法，在尝试与 DAL 通信时应该由 BLL 调用 --> 我的意思是，这 10 个方法是由 DAL 的基础抽象类定义还是由接口定义更好？跨度>
-
通常对于 BLL，您有继承自的基类，但它们可能并不总是抽象的。对于 DAL，通常我有一些标准化的接口。
-
如果我也可以问这个 - 我知道您提供的链接是关于接口与抽象类的，但我认为在层的上下文中，我们应该根据一些不同的论点而不是提到的论点来决定在您提供的链接中？！
-
分层是系统的逻辑分离，它必须提供某种解耦好处 - 具有一致的接口或基类会有所帮助，但这不是必需的 - 您可以简单地使用不同的类并修改直到编译器错误消失;-)。接口和抽象类有助于实现这一点，但它们只是语言提供的一个实现工具——它们有助于定义接口契约，但这实际上只是第一步——它们通常不能走得足够远来强制执行你期望的每一个行为/需要。
-
非常感谢您的帮助