命名空间/解决方案结构答案

【问题标题】：Namespace/solution structure命名空间/解决方案结构
【发布时间】：2010-09-05 22:47:27
【问题描述】：

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

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

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

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

【问题讨论】：

标签： architecture module namespaces legacy

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

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

一开始真的很难，因为有这么多。我认为我能给出的最佳建议是在周五下午的风雨中投入时间，在接下来的几周内，我会选择一个应用程序/代码块，检查什么是在那里，想想我们可以制作通用的东西，复制它，把它放到我认为应该放在的新库中。一旦我迁移了应用程序中的所有代码，我就会着手重构应用程序以从通用框架中工作。这有时会导致需要修复的问题，但只要你彻底它不应该太大一笔交易。

一块一块的，这是唯一的办法。

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

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

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

抱歉，这篇文章太长了……有点漫无边际！

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

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

我们摘自 Krzysztof Cwalina（作者）、Brad Abrams（作者）的一本书电话 Framework Design Guidelines

【讨论】：

【解决方案5】：

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

这是一个解释 DTO 的链接：

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

【讨论】：

【解决方案6】：

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

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

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

【讨论】：