posts - 56, comments - 77, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

代码的物理组织

Posted on 2010-06-20 23:37 切尔斯基 阅读(2073) 评论(2)  编辑  收藏
同一个Feature的代码要放在一起(IDE里单独的一个工程, 或者工程里单独的一个文件夹), 这些代码要么全有要么全无的, 它们合作完成一个Feature, 如果用户不再需要这个Feature了, 可以把它们整个的痛快的删掉, 不会留下谁也用不到的代码成为系统的垃圾. 如果想看一个Feature是如何实现的, 那所有相关代码都在一起, 不需要在庞大的代码库中跳来跳去.

那么理想的情况就是: 你看看源代码树里所有工程文件的名字, 或者文件夹的名字, 就知道系统提供了哪些功能, 它可以跟你的需求描述对应起来, 无论用User Story还是Use Case, 都可以用它们的名字作为工程名或者文件夹的名字, 方便维护


流行的MVC框架缺省的物理文件组织并不是这样的, Controller, Model, View分别在不同的文件夹里面. ASP.Net MVC提供了VirtualPathProvider以及ViewEngine, 可以让我们把一个Feature的Controller/Model/View统统打包到一个project或者文件夹而运行时依然能够找到对应的action和view, 这是我们正在利用的特性


这种代码组织方式对架构的影响是什么?

这基本会导致基于插件/扩展点的体系结构. 放到更大尺度上, 就是SOA. SOA才是王道. 这个词太大了, 还是先聚焦到一个进程的应用....

1. UI如何聚合? 最终用户看到的UI, 是一个聚合的结果, 可能来自系统的不同部分. 解决这个问题的扩展点技术有客户端的Ajax, 或者服务端的RenderAction. (问题: Css应该如何处理? 不同部分的显示顺序, 布局如何确定?)
2. Feature如何沟通? Feature之间不可能一点依赖没有, 比如可能会用到相同的数据, 相同的业务逻辑. 解决这个问题的方法有Bounded Context, Context Mapping, DCI...都是一回事
3. 数据库如何划分? 不同的Feature使用自己的独立定义的数据表, 做映射和同步, 也是同样的方案
4. 如何把这些Feature组装在一起? Java平台有OSGi, .Net目前没有看到跟OSGi类似的方案. 基本是注册或动态发现的路子, 遵循开闭原则...



评论

# re: 代码的物理组织  回复  更多评论   

2010-06-21 11:00 by anders
非常正确,这其实是分析模型到设计模型到实现模型的一种直接的映射关系。
不仅仅是MVC,甚至于n-Tier模型都是存在同一个问题——它们是很好的技术模型,但不是很好的信息模型。

从需求开始就是我们有这样这样或者那样的组件及其功能,开发过程中的用例、分析都是以功能为主线组织的,可是到了实现模型(代码),就变成了MVC或者n-Tier要求的技术工件划分,于是代码被分割了。

没有人能购快速的找到一个功能对应的代码,另一方面这样的划分违反了包的稳定性原则。

# re: 代码的物理组织  回复  更多评论   

2010-06-21 13:34 by chelsea
@anders

看了你的这篇http://www.blogjava.net/AndersLin/archive/2010/02/21/313521.html, 看来有类似的问题类似的想法

只有注册用户登录后才能发表评论。


网站导航: