命名空间/解决方案结构

我为提出这样一个普遍的问题而道歉,但这对我来说是个挑战.我的团队即将开始一个大型项目,希望能够将所有随机的一次性代码库集中在一起.鉴于该项目将涵盖整个公司的标准化逻辑实体("客户","员工"),小任务,控制小任务的大型任务以及公用事业服务,我正在努力找出构建公司的最佳方式.名称空间和代码结构.

虽然我想我没有给你足够的细节继续,你是否有任何关于如何在逻辑上分割你的域的资源或建议？如果它有所帮助,大部分功能将通过Web服务显示,我们是一家拥有所有最新小玩意和小工具的微软商店.

我正在讨论一个带子项目的大规模解决方案,以便让参考更容易,但是这会让它太笨重吗？

我是否应该包含遗留应用程序功能,或者在命名空间中保留完全不可知(例如,将OurCRMProduct.Customer类与通用Customer类相比)？

如果每个服务/项目有自己的BAL和DAL,或者应该说是一个完全独立的组件都引用？

我没有组织这些影响深远的项目的经验,只有一次性的,所以我正在寻找我能得到的任何指导.

有一百万种皮肤养猫的方法.然而,最简单的一个总是最好的.哪种方式最简单？取决于您的要求.但是我遵循一些一般的经验法则.

首先,尽可能减少项目总数.当你每天编译二十次时,额外的分钟就会增加.

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

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

简化您的解决方案.如果它看起来太复杂,它可能是.结合,减少.

我的建议,即开始了类似的事业,是不要为名字空间而痛苦.

只需从一些重要的松散指南开始开发,因为无论你从哪开始,你的项目都是有机的,你最终会重新组织名称空间和类.

不要浪费时间过多地谈论你的项目.去做就对了.