命名空间/解决方案结构-解网

问：

我很抱歉问这样一个笼统的问题，但这对我来说可能是一个挑战。我的团队即将开始一个大型项目，希望能够将多年来发展的所有随机一次性代码库整合在一起。鉴于这个项目将涵盖整个公司的标准化逻辑实体（“客户”、“员工”）、小任务、控制小任务的大任务以及实用程序服务，我正在努力找出构建命名空间和代码结构的最佳方法。

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

我正在讨论一个带有子项目的大规模解决方案，以使引用更容易，但这会不会让它变得太笨拙？
我应该包抄遗的应用程序功能，还是在命名空间中完全不可知（例如，创建一个类与一个泛型类）？OurCRMProduct.CustomerCustomer
每个服务/项目都应该有自己的和，还是应该是一个完全独立的程序集，所有内容都引用？BALDAL

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

体系结构模块命名空间旧版

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

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

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

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

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

对不起，这篇文章很长..这有点漫无边际！

0赞 Keith 8/15/2008 #3

具有大量项目的大型解决方案的编译速度可能非常慢，但更容易一起管理。

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

4赞 Jedi Master Spooky 8/15/2008 #4

我们按以下方式命名 .NET 中的程序集：Company.Project.XXXX.YYYY，其中 XXXX 是 Project，YYYYY 是子项目，例如：

LCP。AdmCom.Common
LCP。AdmCom.BusinessObjects
LCP。AdmCom.Common.Dal

我们从Krzysztof Cwalina（作者），Brad Abrams（作者）的一本书《框架设计指南》中摘取了这一点

3赞 Dale Ragan 8/15/2008 #5

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

以下是解释 DTO 的链接：

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

7赞 Seibar 8/15/2008 #6

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

只需从一些重要的松散准则开始开发，因为无论您如何开始，您的项目都是有机的，并且随着时间的推移，您最终会重新组织命名空间和类。

不要浪费时间过多地谈论你的项目。只管去做。

上一个：有没有一种“简洁”的方法来在 JavaScript 中进行命名空间？

下一个：XPATHS 和默认命名空间

命名空间/解决方案结构

Namespace/solution structure

评论