我在企业工作,我们在解决方案项目中使用多个项目,用于UI,业务逻辑和数据访问,数据库和另一个用于打印....但现在我在新的企业,经理告诉我,我不做我必须完成所有这个项目,只需要将它们放入解决方案中的一个项目中的单独目录中.
我只是想知道我是否必须说服他使用多个项目!
STW*_*STW 68
我对接受的答案感到非常惊讶.我曾在两种环境中工作,并且发现多个项目总体上是有益的.实际的决定仍然取决于你的团队(如果一个项目没有阻止你实现你的目标,那就足够了).
我依靠Bob叔叔关于包管理的OOD原则.这些并不是很清楚(特别是与他的SOLID原则相比,他们的课堂设计),但它们是明智的.
摘自鲍勃叔叔的OOD原理
前三个包的原则是关于包内聚,它们告诉我们在包内放什么:
- REP释放重用等效原则重用的颗粒是释放的颗粒.
- CCP共同关闭原则一起更改的类被打包在一起.
- CRP共同重用原则将一起使用的类打包在一起.
最后三个原则是关于包之间的耦合,并讨论评估系统包结构的指标.
- ADP非循环依赖关系原则包的依赖关系图必须没有循环.
- SDP稳定的依赖原则取决于稳定性.
- SAP稳定抽象原则抽象性随着稳定性而增加.
这符合我个人的经验,在这种经历中,倾向于减少项目经常导致我的经验出现问题:
较少的包可能导致差的依赖管理.单独的项目/程序集可以帮助保持内部/私有类和成员不被使用
通常,在许多项目中,您需要开发一个非常稳定且经过测试的"核心"库集,这些库很少会发生变化.将这些组件保存在他们自己的项目中(甚至是解决方案)可以帮助将他们与更高级别层中的持续更改隔离开来.
使用较少(或单个)项目产生的大型项目可能非常难以驾驭.Visual Studio不会设置您的Project/Solution镜像文件结构的期望,因此有组织的大型项目仍然可以作为驱动器上的混乱存在.
Visual Studio非常智能,可以避免重新编译没有更改的程序集.随着您的"核心"项目稳定,他们将看到更少的编译,这可以节省编译时间.
与上述类似,使用较少的项目会导致始终重新编译代码 - 无论代码是否有相关更改.在一个非常大的项目中进行单行更改将导致完全重新编译.
当然,多个项目也有问题:
您必须对依赖关系保持一致,以避免循环引用(.NET处理得相当好,但Visual Studio可以防止)
您的解决方案可能会变得足够大以保证子解决方案,这可能很难管理
解决方案的初始编译时间可能较慢
最后,.NET中一个很少使用的功能是单个.DLL可以包含多个模块(实际上它是几个共享一组元数据的程序集).我不建议使用它,但知道它是如何工作的很有趣:http: //www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge
Ode*_*ded 52
我实际上同意你的经理.
多个项目意味着多个程序集,大量复制程序集,以及通常较慢的编译时间.
如果您拥有多个项目的唯一理由是改进组织,那么您做错了.使用文件夹同样有效.
拥有不同程序集的一些正当理由是:
我发现了一篇关于结构(项目或文件夹)在应用程序中的重要性的有趣文章.我会说,当你打开一个解决方案并看到一个项目列表时,这些名称会告诉我应用程序是如何构建的.等等
(MVP设计模式示例)
目录结构是您的代码的基础
"正如任何设计师都会告诉你的那样,这是设计过程中最重要的第一步.创造形式的前几个笔画在其中承载着其余部分的命运." - 克里斯托弗亚历山大
(克里斯托弗亚历山大是一名建筑师.没有作为程序员,他影响了许多对编程有很多想法的人.他的早期着作"模式语言"是设计模式运动的最初灵感.他一直在思考如何构建美丽的东西,这些反思似乎也很大程度上适用于软件构建.)
在接受CBC电台采访时,亚历山大讲述了以下故事(在此解释):"我和我的一个学生一起工作.他很难建立一些东西.他根本就不知道该怎么办.所以我和他坐在一起,我说:听着,首先要弄清楚最重要的是什么.先把它弄好.把它直接放在你的脑海里.慢慢来.不要太仓促.考虑一下一段时间.当你觉得自己已经找到它时,当你心中毫无疑问这确实是最重要的事情时,请继续做出最重要的事情.当你做出最重要的事情时,问问自己如果你能让它变得更美丽.切断废话,只要把它直接放在头上,如果你能做得更好或更好.当这样做,你觉得你不能做得更好,那么找到下一个最重要的事情".
应用程序中的第一个笔划是什么,它创建了它的整体形式？它是目录结构.目录结构是程序员在浏览源代码时遇到的第一件事.一切都从它流出.一切都取决于它.这显然是源代码最重要的方面之一.
考虑程序员遇到不同目录结构时的不同反应.对于逐个功能的样式,应用程序员的想法可能是这样的:
"我明白了.它一次性列出了应用程序的所有顶级功能.很好." "让我们看看.我想知道这个项目的位置......哦,这就是它.我需要的其他一切也就在这里,所有这些都在同一个地方.很棒." 然而,对于逐层的风格,应用程序员的想法可能更像是这样:"这些目录没有告诉我.这个应用程序中有多少功能？打败我.它看起来和其他所有功能完全一样.没有任何区别.很棒.我们再来一次......""嗯.我想知道这个项目的位置......我猜它的各个部分都在应用程序上,遍布所有这些目录.我真的有我需要的所有物品？我想我们以后会发现的." "我想知道这个命名约定是否仍然被遵循.如果没有,我将不得不在另一个目录中查找它." "哇,你看看这个单一目录的大小......谢谢." 其他域中的逐层分组无效
因为关注点分离.这将极大地帮助类/对象之间的意外引用.
对于WPF/Silverlight程序员,请考虑MVVM设计模式:将ViewModel和Views分成两个不同的项目将确保View对象没有引用到ViewModel中.
另一点是构建时间可能会缩短,因为每次都不会重新编译整个解决方案.对于您的经理来说,这可能是一个很好的论据(但根据您的解决方案的规模,这个假设可能是错误的).
如果你只曾经有一个应用程序,比一个项目是罚款.但我认为这是非常罕见的.大多数情况下,您将拥有多个应用程序,因此通过拥有多个项目,您可以在应用程序之间重用组件,而无需执行共享源文件等hacky.
| 归档时间： |
|
| 查看次数： |
29583 次 |
| 最近记录： |