答案 0 :(得分：1)
我冒昧地在两个主要问题中总结你的帖子。我希望我能抓住你所要求的本质。
Q） DAL公开的接口与BLL公开的接口之间有什么关系？
A） BLL是一个面向外部的API，因此它应该实现对应用程序的外部消费者有用的功能公开它以一种对他们有意义的方式 相反，DAL是一个面向内部的API，它以隐藏正在使用的存储机制细节的方式公开功能以检索和保留数据。
简而言之，DAL侧重于如何在应用程序内部表示和管理数据，而BLL则侧重于以对消费者有意义的方式公开数据。
Q） 公共API应该有多少种方法，哪些方法？
A） API的设计与其实现的目标和使用对象密切相关。
实际上，这意味着您应该了解API的目标受众，并仅向他们提供完成工作所需的内容
由于无法预测API的所有可能使用方式，因此决定支持哪些主要用例非常重要，并努力使其在API中非常简单。要记住的一个好原则是艾伦凯曾经说过：
简单的事情应该很简单， 复杂的事情应该是可能的。
可以在API中构建一些扩展点以获得一定程度的灵活性。实现此目的的常用方法是使用接口来定义API的行为。这将允许消费者通过提供自定义实现来替换或扩展内置功能的部分。
对于您的观点，我认为最好在
另一方面在DAL 中使用许多较小的以数据为中心的方法来处理特定的数据片段是完全正确的。
<强>更新
关于界面
层之间应存在接口。更具体地说，类应该通过接口专门与来自其他层的类交互。
例如，DAL应公开用于访问数据的类的接口，例如 IOrderHeaderTable 或 IOrderRepository ，具体取决于所使用的设计模式。
BLL应该公开用于执行业务操作的类，例如 IOrderManagementWorkflow 或 ICustomerService 。
注意：层内的常用功能仍然可以放在基类中，因为在现代的面向对象语言（如C＃，VB.NET和Java）中，类可以从基类继承并实现一个或者更多接口
此外，希望通过实现任何提供的公共接口来定制内置功能的外部方可以这样做，而无需访问源代码。然而，接口应该是自我描述和良好记录的，以便扩展器易于理解其语义。
关于BLL
BLL应该明确它支持的业务逻辑。因此，拥有与业务操作直接相关的方法通常是个好主意。
为了更加清晰，我认为最好有一个接受单个参数的方法，而不是重载方法来处理不同的参数。 。此参数将是一个对象，其中包含要使用的方法的所有数据。有些数据可能是必需的，有些可能是可选的，会影响操作的效果
实现细节：ASP.NET Web窗体中内置的ObjectDataSource控件完全支持这种BLL API。
关于API
API应包含设计人员可以提出的所有方法，在API旨在支持的用例定义的范围内。