先看评论。。。


《企业应用架构模式》读书笔记(1)
Posted on 2005-05-12 13:41 马维峰 阅读(762) 评论(8) 编辑 收藏
关于书，我觉得没有资格说什么，零碎记录了自己的一些想法，欢迎讨论指正。

引言：关于性能的考虑

Fowler强调，关于性能，一定要“眼见为实”，各种关于性能的条条框框，如果没有在具体配置里运行一下，是没有说服力的。

这一点，个人非常赞同，拿熟悉的VB来说话，对于Variant类型，性能和内存损失没有一般人认为的那么大，《Advance Visual Basic 6》一书有专门说明，自己测一下也就明白了。反而是，在实际工作中，见到很多人，声明了对象、窗体，使用完成后没有将引用设置为Nothing，因为COM是基于引用计数来进行垃圾回收，如果不及早将对象设置为Nothing，可能要到程序结束时才回收这些对象，而损失了大量效率。而且，在GIS之类的二次开发中，对象中往往有GDI句柄等重要资源，如果对象是在其销毁时释放这些资源，那么使用这些对象就应该，也必须及早将其释放（设置为Nothing）。

第一章：关于分层

书中对分层概念讲解的非常清晰，非常值得反复细读。

关于层次结构的优势

层次结构，对于企业系统，优势在于将领域逻辑（业务代码）放在中间层，而使程序各层关注的焦点不同。

前些天一直在想一个问题，即如果一个系统，在开发过程中如果需要在数据库增加一个字段，那么，所有各层（实体、业务逻辑、界面）不是都要修改，那么，层次结构如何来应付这种情况。MSDN的Provider模式介绍时引入了类似问题，也给出了一个解决方案，但这样效率、关系数据库的优势以及很多其他问题都会引入。

这几天看《企业应用架构模式》，忽然明白，这样的情况不是不存在，但不是主要问题，也不是系统需要分层的原因，层次架构是需要将业务逻辑（复杂的、多变的）独立出来，是为了解决这个问题。而对于以上问题，为什么会在我看来是一个问题，关键在于，国内信息化还仅仅是Fowler介绍客户/服务器2层系统时所言的简单的数据显示和修改，2层系统也可以应付。至于出现修改字段，问题在于需求工作没有做好。大概如此而已。


分层：分层时，对于很小的系统，即使一个过程，也需要尽量把数据、业务、表现分开；对于大一些的系统，可以使用不同的过程（函数），而对于更大的系统，可以使用不同的类。

在分层的时候，一定要注意，数据层和领域层绝对不能依赖表现层，即领域层、数据层代码中，绝对不能有调用表现层的代码。

而领域层和数据层之间，需要根据具体情况考虑。

对于各功能，看是否可以放在某一层，主要要看替换掉某些层，例如表现层由Web界面换为命令行界面，是否有效。同时，如果某些功能，需要重复在一层实现，那么，应该是在下一层实现的功能在本层实现了。

Feedback
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 14:05 by idior
增加一个字段,不会影响到业务层.
只是影响orm层
除非对象的属性也增加了.
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 14:10 by 马维峰
经常是需要增加属性的，而且这个属性好需要在界面中输入或者选择。
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 14:37 by neuhawk
企业的需求常变化的阿，所以添加字段也是正常。
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 14:46 by age0
工作量跟多少层没什么关系，只跟引用数量有关，就算是两层也同样要改界面、业务逻辑和数据存储的代码。举个例子，如果一个系统有10个界面，而每个界面恰好都要引用新增字段，那么意味着1x10的工作量，但是如果系统架构能够把工作量维持在1x1，那么这个架构就会比任何n层架构NB十倍。
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 15:10 by simonw
业务需求发生变化导致增加字段，那么业务逻辑，依赖业务逻辑的部分，业务数据变化是无法避免的
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 15:13 by 马维峰
to age0: 我就是这个意思，不过个人觉得，这种需求虽然不能完全避免，但至少在需求分析做得比较好的情况下会很少。

而且，对于应用，敏捷开发这样的开发实践，通过缩短每次迭代开发的时间，逐渐增加功能，了解客户需求。
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 16:40 by 小陆
类似于加字段这样的事情肯定是不可避免的，无论需求调查的多么完美。并且发生更大规模的变化也是正常的。我们必须承认需求的变化，就是要承认我们在某些方面是无知的，我们必须在这样的情况下设计、编码、设计和编码。我们所能做的是减少可能的变更带来的冲击力。当然方向性的问题不能错。
按照面向过程的设计方式，设计人员从一开始就是进行业务过程的分解，将一个大的、模糊的过程进行层层分解，最终成为一个个小的、清晰的任务，分析这些过程，复用相同的部分，然后开始编码，如果这个时候发现某个过程的需求发生了变化，就会影响到一串过程，也许某些过程的次序要发生变化，参数要增加或者修改，难免影响到与此交叉的其他过程。采用这样的思想，开发工作过程最好是这样：告诉我需求，然后你走开，我来开发，等做完了我拿出来给你看。
如果换一种思路，可以将系统在不同抽象程度上建立不同的层次，最初的系统建立在一系列interface上，在此基础上进行实现，这样，模块之间的实现就隔离了。即使这样，如果发生类似于文章中的变化：界面上要加一个显示条目，同时数据库加一个字段，带来的变化也是比较多的，很多文件都要修改。但是可以放心，只有真正关心这个字段（属性）的地方才会受到影响。并且，如果采用一些技巧（也许可以采用Decorator模式，或者其他方法），需要修改的代码其实很少，也许只要为某个接口添加一个新的实现，然后再改改配置文件就可以了，这样，引入bug的可能性就大大降低了。
# re: 《企业应用架构模式》读书笔记(1)
2005-05-12 17:46 by neuhawk
象ORM这类的东西，每次添加字段，都要改代码，实施的时候，有点麻烦了。