关于架构：命名空间/解决方案结构

很抱歉提出如此笼统的问题，但这对我来说可能具有挑战性。我的团队即将开始一个大型项目，希望将多年来发展起来的所有随机一次性代码库拖到一起。鉴于该项目将涵盖整个公司("客户"、"员工")、小任务、控制小任务的大任务和公用事业服务的标准化逻辑实体，我正在努力找出构建命名空间和代码结构。

虽然我想我没有给你足够的细节来继续，但你有关于如何合理地拆分你的域的任何资源或建议吗？如果有帮助，大部分功能将通过网络服务显示，我们是一家 Microsoft 商店，提供所有最新的小玩意和小工具。

• 我正在讨论一个包含子项目的大型解决方案，以使引用更容易，但这会使其过于笨拙吗？
• 我应该结束遗留应用程序的功能，还是在命名空间中完全不可知(例如，创建一个 OurCRMProduct.Customer 类与一个通用的 Customer 类)？
• 每个服务/项目应该有自己的 BAL 和 DAL，还是应该是一个完全独立的程序集，所有内容都引用？

我没有组织如此影响深远的项目的经验，只有一次性的，所以我正在寻找我能得到的任何指导。

---

有一百万种给猫剥皮的方法。然而，最简单的总是最好的。哪种方式对您来说最简单？取决于您的要求。但是我遵循一些一般的经验法则。

首先，尽可能减少项目总数。当您一天编译 20 次时，额外的一分钟就会加起来。

如果您的应用是为可扩展性而设计的，请考虑按照设计与实现的路线拆分您的程序集。将您的接口和基类放在公共程序集中。为您公司的这些类的实现创建一个程序集。

对于大型应用程序，请将 UI 逻辑和业务逻辑分开。

简化您的解决方案。如果它看起来太复杂，它可能是。合并，减少。

---

我的建议是，在开始类似的工作后，不要为命名空间而烦恼..

只需根据一些重要的松散指南开始开发，因为无论您如何开始，您的项目都是有机的，随着时间的推移，您最终会重新组织名称空间和类。

不要浪费时间过多谈论您的项目。就去做吧。

---

我们将 .NET 中的程序集命名为 Company.Project.XXXX.YYYY，其中 XXXX 是项目，YYYYY 是子项目，例如：

• LCP.AdmCom.Common
• LCP.AdmCom.BusinessObjects
• LCP.AdmCom.Common.Dal

我们从 Krzysztof Cwalina(作者)、Brad Abrams(作者)合着的一本名为《框架设计指南》的书中获取了这一点

---

我最近在工作中遇到了完全相同的情况。许多需要结构化和组织的临时代码。

一开始真的很难，因为太多了。我认为我能给出的最好建议是在周五下午放松的时候花时间在它上面，有几个星期我会选择一个应用程序/代码块，检查那里有什么，想想我们可以做什么通用，复制它，把它放到我认为应该放在的新库中。一旦我迁移了应用程序中的所有代码，我就会着手重构应用程序以从通用框架开始工作。这有时会导致需要修复的问题，但只要您彻底解决它就不应该太大不了。

一点一点，这是唯一的方法。

在结构方面，我试图模仿 MS 命名空间，因为在大多数情况下它非常合乎逻辑(例如 Company.Data 、 Company.Web 、 Company.Web.UI 等等。

主要好处之一可能是删除了大量的代码重复。是的，应用程序需要进行一些重构，但代码库要精简得多，并且在很多方面都"更智能"。

我注意到的另一件事是，我经常在试图弄清楚将东西放在哪里时遇到问题(在命名空间方面)，因为我不确定它属于什么。现在这让我很担心，我认为它是一种难闻的气味。由于重组，现在一切都更好地归入空间。并且使用(现在非常少的)应用程序特定代码，它们被放入 Company.Applications.ApplicationName 这有助于我真正考虑更多的业务对象，因为我不想在这个命名空间中有太多，所以我想出了更多灵活的设计。

抱歉长篇幅.. 有点啰嗦！

---

对于大型项目，我喜欢采用的方法是为我的业务对象使用一个域命名空间，然后在需要存储和检索业务对象的层中使用数据传输对象 (DTO\\'s)。 DTO 是一个不包含任何业务逻辑的简单对象。

这是一个解释 DTO 的链接：

http://martinfowler.com/eaaCatalog/dataTransferObject.html

---

包含大量项目的大型解决方案的编译速度可能会很慢，但更易于一起管理。

我经常将单元测试程序集与他们正在测试的程序集放在同一个解决方案中，因为您倾向于一起对它们进行更改。

---