我正在寻找关于在.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中创建解决方案文件夹,这些是可用于对解决方案中的项目进行分组的虚拟文件夹。右键单击解决方案资源管理器中的解决方案,并创建一个测试文件夹,作为示例,您可以将测试项目放在那里,将项目设置到另一个等等...您可能还想分解其他域