什么是更好的,许多小型组件,或一个大型组件？

一切都在标题:)

目前,我们有一个VS2005解决方案,包含20多个项目.喜欢

MySolution
MySolution.Modules.Foo
MySolution.Modules.Bar
[insert many here]
MySolution.Modules.Baz

在一个项目中"合并"MySolution.Modules.*会有害吗？将保留所有名称空间,因此这里没有问题.

但有什么我没想过的吗？

注意:目前,不能有循环引用:如果MySolution.Modules.Foo引用MySolution.Modules.Bar,MySolution.Modules.Bar不能引用MySolution.Modules.Foo.所以我们必须小心不要创造一些.

我曾经在几家公司工作,有太多的项目在各方面都很痛苦.我还没有去过任何地方其中有过一些项目,虽然这当然是可能的.

将项目视为重用的一个单元,以及其他方面.是否有任何产品需要Foo而不是Bar,反之亦然？如果没有,将它们合并在一起.

我喜欢将不同的层(表示,业务逻辑,数据访问)分开,并且拥有一个与产品无关的通用实用程序库是很好的,但在许多情况下这都是关于它的.

哦,并将测试保存在与生产代码不同的项目中,当然:)

一个组件的优点:

潜在的

可能更容易部署

许多组件的优点:

其他一切.假设这些是良好的内聚模块,它有助于分离关注点,通过强制您考虑对架构进行调平/分层等来控制依赖关系.

我们使用ILMerge将所有小组件绑定到一个更大的块中.特别是在不同项目中但最终属于同一名称空间的程序集.

例如,我们有很多数据实体用于记录和视图分布在许多程序集,MJ.DE.views.dll,MJ.DE.tables.dll,MJ.DE.sprocs.dll等,但最后我们使用ILMerge将它们绑定到一个MJ.DE.DLL中. - 使更新/同步应用程序更容易,因为生产服务器上有更少的小块,我们知道所有相关的类都来自同一个编译.