《企业应用架构模式》读书笔记(1)

关于书，我觉得没有资格说什么，零碎记录了自己的一些想法，欢迎讨论指正。

引言：关于性能的考虑

 

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

 

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

 

第一章：关于分层

 

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

 

关于层次结构的优势

 

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

 

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

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

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

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

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

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