我为提出这样一个普遍的问题而道歉，但这对我来说是个挑战。我的团队即将开始一个大型项目，希望能够将所有随机一次性代码库集中在一起。鉴于该项目将涵盖整个公司的标准化逻辑实体（“客户”，“员工”），小任务，控制小任务的大型任务以及公用事业服务，我正在努力找出构建公司的最佳方式。名称空间和代码结构。
虽然我想我没有给你足够的具体细节，但你是否有任何关于如何在逻辑上分割你的域的资源或建议？？如果它有所帮助，大部分功能将通过网络服务显示，我们是一个 Microsoft 商店，包含所有最新的小玩意儿和小工具。
OurCRMProduct.Customer类而不是通用Customer类）？ BAL和DAL，还是应该是一个完全独立的程序集，一切都引用？ 我没有组织这些影响深远的项目的经验，只有一次性，所以我正在寻找我能得到的任何指导。
答案 0 :(得分：12)
有一百万种皮肤养猫的方法。然而，最简单的一个总是最好的。哪种方式最简单？取决于您的要求。但是我遵循一些一般的经验法则。
首先，尽可能减少项目总数。当你每天编译二十次时，额外的分钟就会增加。
如果您的应用程序是为可扩展性而设计的，请考虑按照设计与实现的方式拆分程序集。将接口和基类放在公共程序集中。为您公司的这些类的实现创建一个程序集。
对于大型应用程序，请将UI逻辑和业务逻辑分开。
简化您的解决方案。如果它看起来太复杂，它可能是。结合，减少。
答案 1 :(得分：7)
我的建议是，在开始类似的工作之后，不要为名称空间而痛苦。
刚开始使用一些重要的松散指南进行开发，因为无论如何开始，您的项目都是有机的，并且将最终重新组织名称空间和类。
不要浪费时间过多地谈论你的项目。就这么做。
答案 2 :(得分：4)
我最近在工作中经历了完全相同的事情。需要构建和组织的大量特殊代码。
起初真的很难，因为有这么多。我认为我能给出的最好的建议就是在周五下午的时候投入时间，几周后我会选择一个app / chunk代码，检查是什么在那里，想想我们可以制作通用的东西，复制它，把它放到新的库中，无论我认为它应该在哪里。一旦我迁移了应用程序中的所有代码，我就会努力重构应用程序以便从公共框架中工作。这有时会导致需要修复的问题，但只要你彻底的不应该太大一笔交易。
一块一块，这是唯一的方法。
在结构方面，我试图模仿MS命名空间，因为它大部分都是非常合乎逻辑的（例如 Company.Data ， Company.Web ，< em> Company.Web.UI 等等。
其中一个主要好处可能是删除了代码数量。是的，在应用程序中需要进行一些重构，但代码库更加精简，并且在很多方面“更聪明”。
我注意到的另一件事是，我经常会遇到问题，试图找出 where 来放置东西（就命名空间而言），因为我不确定它属于什么。现在这个非常关注我，我认为这是一种难闻的气味。因为重新组织现在所有的东西都更加美好。使用（现在非常少量）应用程序特定代码，它们被放入 Company.Applications.ApplicationName 这有助于我真正考虑业务对象，因为我不希望在这个命名空间中有太多，所以我提出了更灵活的设计。
很抱歉这篇长篇大论..这有点像漫无边际！
答案 3 :(得分：4)
我们使用以下方式在.NET中命名程序集Company.Project.XXXX.YYYY其中XXXX是Project而YYYYY是子项目，例如：
我们从Krzysztof Cwalina（作者），Brad Abrams（作者）的书本Framework Design Guidelines中得到了这一点
答案 4 :(得分：3)
对于大型项目，我喜欢的方法是为我的业务对象设置一个Domain命名空间，然后在我需要存储和检索业务对象的层中使用数据传输对象（DTO）。 DTO是一个不包含任何业务逻辑的简单对象。
这是一个解释DTO的链接：
答案 5 :(得分：0)
包含大量项目的大型解决方案编译速度很慢，但更易于管理。
我经常在与他们测试的解决方案相同的解决方案中使用单元测试程序集，因为您倾向于对它们进行一起更改。