程序集、命名空间、DAL；哪些类属于哪里？答案

【问题标题】：Assembly, Namespace, DAL; What classes belongs where?程序集、命名空间、DAL；哪些类属于哪里？
【发布时间】：2011-06-15 11:09:47
【问题描述】：

我想了解一些关于程序集和命名空间的基础知识。我已经复制了 NHibernate 教程，一切正常。但我不确定我是否同意哪些课程去哪里。所以看看附加的解决方案资源管理器图片..

Domain 和 Repositories（在文件夹中包含类）是 命名空间。这两个都在 ...DAL 程序集中。

有什么合乎逻辑的理由把它放在那里吗？ Product 是一个 POCO 类。那不应该更自然地属于 DAL 程序集之外吗？
将 IProductRepository 放在 Domain 命名空间中是否正确？如果您建议移动 POCO 类，您还会移动 IProductRepository 吗？
如果我想让 DAL 可供 C# 和 VB.NET 项目使用，我需要做什么？

【问题讨论】：

标签： c# .net namespaces data-access-layer

【解决方案1】：

通常我会将 POCO 放在它们自己的库中，例如 MyProject.Model 或您所称的“域”。原因是我可能也想在 DAL 之外使用它们，在食物链的某个更高的地方，而不参考 DAL 程序集。例如，我可能会在 .DataAccess 前面加上一个 .Business 项目，该项目将返回相同的 .Model（域）对象。例如，通常我的存储库位于 MyProject.DataAccess.Repositories 中。您应该能够毫无问题地从任何项目引用 .NET 程序集（无论是 C# 还是 VB.NET）。

【讨论】：

【解决方案2】：

有什么合乎逻辑的理由吗？那里？产品是 POCO 类。那不应该更自然地属于在 DAL 程序集之外？

将 POCO 类与持久性实现一起放入的理由是简化部署并减少所需程序集的总数。

这并不是说我同意这种做法。

将域对象的定义放在一个程序集中，将依赖于持久性技术的实现放在另一个程序集中，这是一种更好的做法，甚至可能更传统。

然后，客户端可以引用域对象定义的组合，而不受实施策略的束缚。

这样写对吗域中的 IProductRepository 命名空间？如果你建议搬家 POCO班，你也搬吗 IProductRepository？

是的，存储库的定义在域中是正确的。

存储库是一个领域概念，它们不是通用的——至少不是它们公开的接口（实现实际上可能是通用的）。

存储库的接口应该与实体的定义（无论它们是 POCO 还是只是接口）以及所有其他域对象一起使用。

如果我愿意，我需要做什么使 DAL 可用于 C# 和 VB.NET 项目？

没什么特别的。无论 DAL 和/或域程序集是用 C# 还是 VB.Net 编写的，您都可以从 C# 或 VB.Net 引用程序集。这是 .Net 整体的一大优势，而且是有意设计的。

【讨论】：

我无法理解通过创建单独的程序集在物理上对域和存储库类进行分区的吸引力，除非是在少数边缘情况下；有什么好处？即使使用单个程序集，也欢迎客户引用域对象定义，而不必使用特定的实现策略。尽管如此，您已经公平地展示了单一组装方法的案例，所以 +1（Patrick Smacchia 更详细地介绍了in an article here）。
@Jeff：不是对域和存储库类进行分区。那不是重点。它是将必须引用持久性技术的类与构成域定义的接口和类分开（并且没有必要或目的引用持久性技术）。
这是一个偏好点，imo，对小型团队来说有些无关紧要。但是在更大、更松散或分布式的团队中，具有这种分离可以防止其他开发人员通过在不适当的地方依赖持久性技术而无意中违反项目准则，因为他们可以（因此不知道更好）。跨度>
谢谢！！我不清楚一件事：如果 POCO 在 DAL 程序集中休息，我相信会拒绝任何外部程序集来扩展它们。如何使成为可能；让一个项目在那些“POCO”中加入一些行为？它们仍然可以跨程序集继承吗？或者，是否可以在 DAL 程序集中同时拥有 POCO 的定义和实现，然后允许每个项目选择使用该实现，或者拥有自己的实现？在这种情况下，我将在 DAL 程序集和项目程序集之间传递什么类型？
您可以从另一个项目继承类，只要该类本身及其至少一个构造函数是可访问的（不是内部的）。但是这些类所谈论的是您的业务对象或域对象，不是吗？如果是这样，那么拥有替代实现似乎毫无意义。此外，不，您不能从一个实现（类）转换为另一个，除非专门实现了这种类型转换。您可以通过对它们共享的接口的引用来持有对任一实现的引用，但不能从一个实现类转换为另一个实现类。