我正在寻找关于在.NET中分离项目的一些建议。我正在构建一个大型Windows窗体应用程序（80个表），我只有几个项目。他们变得很大。前几天我看到引用列表时发现了问题。这是我第一次创建这么大的应用程序，所以项目的命名和它们的分离变得有点混乱。
这就是我所拥有的，以及每个项目的关注点。
ProjectName.Dal（数据访问，这是我自动生成的，我不碰它。）
ProjectName.Bll（存储库，与Web服务通信，生成电子邮件，生成Excel和Word文档）
ProjectName.Model（域对象）
ProjectName.UI（窗体和用户控件）
ProjectName.UI.Web（用于系统的小型Web界面的一些网页）
ProjectName.UI.Controls（通用自定义窗体控件）
ProjectName.UI.Presenters（一些MVP表格的演示者）
ProjectName.Reminder（用于提醒人们做事的应用程序的Web服务）
ProjectName.Tests（处理所有单元测试） - 我不确定每个项目是否应该有一个测试项目，例如ProjectName.UI.Presenters.Tests
答案 0 :(得分：2)
我喜欢将一个单独的程序集与您已经提到过的单独程序集分开，这是一个“代理”项目。
假设您正在使用表示层中的某个Web服务。我不想直接引用表示层中的服务（wcf / .asmx），而是希望有一个专门用于将代理封装到该服务的单独项目。我通常在代理本身周围有一个包装类，以帮助管理错误并确保代理始终可用于表示层（或者如果没有则提供良好的异常），并且还提供代理之外的良好表示层对象。例如，我可能想要将Widget []而不是Wilets的DataTable从我的服务传递到我的代理，以使它变得很好并且兼容SO（显然我们不希望将DataTable传递出服务，因为它们都是但是在.xsd级别难以理解）但是DataTables很适合在表示层中绑定，所以我将实际代理包装得到那个widget []，其中'managedProxy'执行从数组到DataTable的转换以及管理代理呼叫。通过将代理层放到类自己的项目中，可以更进一步将代理层分离到类级别的表示层。这使得它更容易移动到当下的下一层。
答案 1 :(得分：1)
据我所知，分离太多了。
我认为最好的结构会是这样的：
测试可以包含在它所针对的每个项目中，在一个单独的文件夹/命名空间中，但这还需要进行另一次辩论。
严重的是，在一个解决方案中包含太多项目不仅会降低您的计算机速度，还会损害您的理智，无论如何仍然可以协同工作。
答案 2 :(得分：0)
使用项目中的文件夹，根据域进一步将您的类与彼此分开。此外，您可以在Visual Studio中创建解决方案文件夹，这些是可用于对解决方案中的项目进行分组的虚拟文件夹。右键单击解决方案资源管理器中的解决方案，并创建一个测试文件夹，作为示例，您可以将测试项目放在那里，将项目设置到另一个等等...您可能还想分解其他域