代码的物理组织
同一个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才是王道. 这个词太大了, 还是先聚焦到一个进程的应用....
?
