GUI，BLL，DAL组织在项目中

我正在阅读有关应用程序层的内容，并希望在我的下一个项目（C＃、. Net）中使用此设计。一些问题：

1. 是否通过名称空间完成层分离？Project.BLL。什么，Project.DAL。什么

2. 按层然后按组件（Project.BLL.Component1）或按组件再按层（Project.Component1.BLL）分离是否更合适

3. 对于我的DAL，是否使用不同的类进一步组织了这一层？如果所有数据库调用都放在一个类中，则没有组织。用不同的类或名称空间将它们拆分会更好吗？

4. DAL类通常是静态的吗？在每次调用其方法之一之前实例化DAL对象似乎很麻烦。

用这些层以正确的方式处理事务的任何其他技巧将不胜感激。

1. 是。还有装配体。
2. 我按层分开，然后按组件分开。
3. 是。有不同的方法，但是我有一个IDatabaseService（抽象了数据库调用的各种方式-这几乎可以是ExecuteScalar / ExecuteNonQuery / ExecuteReader的直接映射），然后是各种数据访问类，按数据类型划分。例如，您可能有一个UserDataAccess类，该类具有用于创建/修改/删除User对象的简单CRUD方法。另一种方法是拥有一个内置CRUD的User对象。

4. 号这使得它多难单元测试。您应该使用依赖项注入将依赖项传递给每个数据访问类（例如IDatabaseService）的构造函数。然后，您可以将数据访问对象传递到业务对象中，如下所示：

   BusinessObject businessObject = new BusinessObject（new DataAccessObject（new DatabaseService（）））; businessObject.PerformOperation（）;

每个业务对象可能需要多个数据访问对象。您的GUI代码还将使用一个或多个业务对象。某些业务对象可能不需要任何数据访问对象，但永远不要直接使用IDatabaseService。

对于问题1和2，请参考马修的答案。

我花了很多时间试图找出构建桌面应用程序DAL的最佳方法。最好的方法实际上取决于应用程序的需求。在我的一个应用程序中，我为每个数据库表创建了一个DA类，该类向一个中央（即单例）DataProvider类进行了注册并处理了CRUD。然后，每个DA类可以决定是否要在RAM中缓存所有表数据（性能！）和/或是否需要具有触发在其他计算机上运行的其他客户端中的自动客户端更新的能力（请考虑多用户）。并发）。这使得添加新的DAL类非常容易，因为它们所需要做的就是遵守注册接口。

并非每个DAL都需要这种功能，但是我确实了解到该方法本身（即单例数据提供程序和具有静态注册的简单DAL类）使我在开始添加新类时的工作变得更加轻松。

除非这是一个非常简单的应用程序，否则我绝对不建议将CRUD构建到更高级别的类中。DAL是数据存储的抽象。如果您决定在将来的某个时候更改数据存储（即使只是使用MySQL而不是MS SQL），您将为此感到非常感谢。加：BLL对象应该由它们的业务逻辑关系构成。DAL对象由它们表示的存储容器的类型构成。差异可能很大。

千万不要让你的DAL类的静态。您在编码速度上获得的收益将导致可测试性和灵活性损失很多倍。