logo标签列表

命名空间/解决方案结构

architecturemodulenamespaceslegacy
10

非常抱歉我的问题太泛泛了，但这对我来说是一个具有挑战性的问题。我的团队即将启动一个大型项目，希望将所有多年演变而来的零散代码库整合在一起。鉴于该项目将涵盖标准化公司内的逻辑实体（“客户”，“员工”），控制小任务和大任务的小任务，以及实用程序服务，我正苦苦思考如何最好地组织命名空间和代码结构。

虽然我猜我没有给你们足够的具体信息，您有任何关于如何逻辑分割域的资源或建议吗？如果可以帮助的话，大部分功能将通过Web服务公开，我们是一个拥有所有最新小玩意儿的Microsoft商店。

  • 我正在考虑使用子项目的一个大型解决方案，以便更容易引用，但是否会使它过于笨重？
  • 我应该包装旧的应用程序功能，还是在命名空间中完全不加区别（例如，创建一个OurCRMProduct.Customer类与通用Customer类）？
  • 每个服务/项目是否应该有自己的BAL和DAL，还是应该是一个完全独立的程序集，所有内容都引用它？

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

6个回答
12

有许多种方法可以解决问题。然而，最简单的方法通常是最好的。对于你来说，哪种方法最简单？这取决于你的需求。但是我遵循一些基本的规则。

首先，尽可能减少项目的总数。当你每天编译二十次时，那额外的一分钟就会累积起来。

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

对于大型应用程序，保持你的用户界面逻辑和业务逻辑分开。

简化你的解决方案。如果看起来太复杂，那么它可能确实如此。合并、减少。

7

我的建议是，不要为命名空间烦恼。我已经开始了类似的工作，但建议只需遵循一些重要的宽松指导方针开始开发，因为无论你如何开始，你的项目都是有机的，随着时间推移，你会重新组织命名空间和类。

不要浪费太多时间讨论你的项目。行动起来吧。

4
我最近在工作中也遇到了同样的问题。有很多需要结构化和组织的临时代码。
一开始真的很困难，因为有太多东西。我认为我能给出的最好建议就是，在星期五下午放松的时候投入时间，几周内我会挑选一个应用程序/代码块，检查其中的内容，考虑我们可以使其通用的部分，复制它并将其放入新库中，无论我认为它应该放在哪里。一旦我将应用程序中的所有代码迁移完成，我将开始重构应用程序以从公共框架中工作。这有时会引起需要解决的问题，但只要你认真对待就不会太大问题。
一步一步地进行，这是唯一的方法。
在结构方面，我试图模仿微软的命名空间，因为大部分情况下它非常合乎逻辑（例如Company.Data、Company.Web、Company.Web.UI等）。
其中一个主要好处可能是删除了大量的重复代码。是的，需要进行一些重构，但代码库更加精简，并且在许多方面“更加智能”。
我注意到的另一件事是，我经常会遇到尝试弄清楚应该把东西放在哪里（就命名空间而言）的问题，因为我不确定它属于什么。现在，经过重新组织，一切都更加得体。有了（现在非常少的）应用程序特定代码，它们被放入Company.Applications.ApplicationName中。这帮助我更多地思考业务对象，因为我不想在这个命名空间中有太多东西，所以我设计得更加灵活。
抱歉发了这么长的帖子... 有点啰嗦！
4
我们在.NET中将程序集命名为Company.Project.XXXX.YYYY，其中XXXX是项目名称，YYYYY是子项目名称，例如：
  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal
我们从一本名为Framework Design Guidelines的书中获取了这个内容，作者是Krzysztof Cwalina和Brad Abrams。
3
对于大型项目，我喜欢采用一个域命名空间来管理业务对象，并在需要存储和检索业务对象的层中使用数据传输对象（DTO）。DTO是一个简单的对象，不包含任何业务逻辑。
这里有一个解释DTO的链接：

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

0

有很多项目的大型解决方案编译速度可能会相当慢，但管理起来更容易。

我通常将单元测试程序集与它们所测试的程序集放在同一个解决方案中，因为你往往会同时对它们进行更改。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接