对于提出这样一个笼统的问题，我深表歉意，但这对我来说可能是具有挑战性的。我的团队即将着手进行一个大型项目，希望将这些年来发展起来的所有随机一次性代码库汇集在一起​​。鉴于该项目将涵盖整个公司的标准化逻辑实体("客户"，"员工")，小型任务，控制小型任务的大型任务以及公用事业服务，因此，我正在努力寻找结构化实体的最佳方法命名空间和代码结构。

尽管我想我没有提供足够的详细信息来继续进行下去，但是我们是否有任何资源或者关于如何逻辑上拆分域的建议？如果有帮助，大部分功能将通过Web服务公开，并且我们是一家拥有所有最新小工具和小工具的Microsoft商店。

• 我正在讨论一个带有子项目的大型解决方案，以使引用更容易，但这会使它变得笨拙吗？
• 我应该包装旧的应用程序功能，还是将其完全保留在名称空间中(例如，创建" OurCRMProduct.Customer"类与普通的" Customer"类)？
• 每个服务/项目应该具有自己的BAL和DAL，还是应该是所有内容都引用的完全独立的程序集？

我没有组织如此广泛的项目的经验，只有一次过的经验，所以我正在寻找可以得到的任何指导。

解决方案

回答

有上百万种猫皮的方法。但是，最简单的总是最好的。哪种方式最适合我们？取决于要求。但是我遵循一些一般的经验法则。

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

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

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

简化解决方案。如果看起来太复杂，则可能是这样。结合，减少。

回答

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

一开始它确实很困难，因为有很多东西。我认为我能提供的最好建议是，在星期五下午顺风而下地花一些时间，在几个星期内，我只会选择一个应用程序/代码块，检查其中的内容，考虑我们可以做什么使其通用，然后将其复制，然后将其放到我认为应该放在的新库中。一旦迁移了应用程序中的所有代码，我便会着手从通用框架重构应用程序。这有时会导致需要修复的问题，但前提是透彻知识不应太大一个交易。

一件一件的事情，那是唯一的方法。

在结构方面，我试图模仿MS名称空间，因为在很大程度上它很合逻辑(例如Company.Data，Company.Web，Company.Web.UI等。

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

我注意到的另一件事是，由于我不确定它是什么东西，所以我经常会在试图找出放置东西的位置上遇到麻烦(就命名空间而言)。现在，这真的让我感到担忧，我认为它是一种难闻的气味。自从改组以来，现在所有东西都可以更好地落入太空了。借助(现在很少的)特定于应用程序的代码，它们被放入Company.Applications.ApplicationName中，这我更多地考虑业务对象，因为在此命名空间中我不需要太多，因此我想出了更多灵活的设计。

抱歉，很长的帖子..这真是个漫无边际！

回答

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

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

回答

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

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

我们从Krzysztof Cwalina(作者)，Brad Abrams(作者)的书名为Framework Design Guidelines的书中得出这一点。

回答

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

这是解释DTO的链接：

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

回答

我的建议是开始类似的工作，不要为命名空间感到烦恼。

刚开始使用一些重要的宽松准则进行开发，因为不管我们是如何开始的，项目都是有机的，随着时间的推移，我们最终将重新组织名称空间和类。

不要浪费时间谈论项目。去做就对了。