程序集，命名空间，DAL;什么类属于哪里？

Question

我想了解一些有关程序集和命名空间的基础知识。我已经复制了一个NHibernate教程，一切正常。但我不确定我是否同意哪些课程在哪里。请查看附加的Solution Explorer图像..

域和存储库（包含文件夹中的类）是命名空间。这两个都在... DAL组装。

1. 有没有合理的理由把它放在那里？ 产品是 POCO 类。难道不应该更自然地属于DAL组装之外吗？
2. 将 IProductRepository 放入域命名空间是否正确？如果你建议移动POCO类，你还会移动IProductRepository吗？
3. 如果我想通过 C＃和VB.NET 项目使 DAL 可以使用，我该怎么办？

Answer 1

  

有没有合理的理由说出来   那里？产品是POCO类。   不应该更自然地属于   在DAL组装之外？

将POCO类放入持久性实现的论点是简化部署并减少所需程序集的总数。

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

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

然后，客户端可以引用域对象定义的程序集，而不必依赖于实现策略。

  

放置是否正确   域中的IProductRepository   命名空间？如果你建议搬家   POCO课程，你也会动   IProductRepository？

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

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

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

  

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

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

Answer 2

通常我会将POCO放在他们自己的库中，就像你调用MyProject.Model或“Domain”一样。原因是我可能想在DAL之外使用它们，在食物链上更高的地方，而不参考DAL组件。例如，我可能会使用.Business项目来处理.DataAccess，它将返回相同的.Model（域）对象。通常，我的存储库存在于MyProject.DataAccess.Repositories中。您应该可以从任何项目中引用.NET程序集（无论它是C＃还是VB.NET）而没有任何问题。