.NET初学者架构设计指南（二）OO设计初次见面
[2] .NET初学者架构设计指南（二）OO设计初次见面
[3] .NET初学者架构设计指南（二）OO设计初次见面
[4] .NET初学者架构设计指南（二）OO设计初次见面
[5] .NET初学者架构设计指南（二）OO设计初次见面
[6] .NET初学者架构设计指南（二）OO设计初次见面
[7] .NET初学者架构设计指南（二）OO设计初次见面
系列文章导航：
.NET初学者架构设计指南（一）Hello world的时代
.NET初学者架构设计指南（四）Model-View-Controller
到这个时候，数据库里面的数据成功转化成了程序里面的对象。非常好！按道理说，剩下的OO之路就该顺理成章了。但是，很不幸，我不知道该怎样用这些Value Object，接下来我就怀着困惑的心情把过程式的代码嫁接在这个OO的基础上了。
我为每一个画面设计出了一个Session Bean，在这个Session Bean里面封装了画面所关联的一切业务流程，让这个Session Bean调用一大堆Value Object开始干活。在Session Bean和页面之间，我没有让他们直接调用，因为据公司的牛人说：“页面直接调用业务代码不好，耦合性太强。”这句话没错，但是我对“业务代码”的理解实在有问题，于是就硬生生的造出一个Helper来，阻挡在页面和Session Bean中间，充当了一个传声筒的角色。
于是在开发中就出现了下面这副景象：每当设计发生变更，我就要修改数据库的设计，用代码生成工具重新生成Value Object，然后重新修改Session Bean里面的业务流程，按照新的参数和返回值修改Helper的代码，最后修改页面的调用代码，修改页面样式。
实际情况比我现在说起来复杂的多。比如Value Object的修改，程序规模越来越大以后，我为了避免出现内存的大量占用和效率的下降，不得不把一些数据库查询的逻辑写到了Gateway和Value Object里面，于是在发生变更的时候，我还要手工修改代码生成工具生成的Gateway和Value Object。这样的维护十分麻烦，这使我困惑OO到底有什么好处。我在这个项目中用OO方式解决了很多问题，而这些问题都是由OO本身造成的。
另一个比较大的问题出在Struts上。投资方为系统设计了很灵活的界面，界面上的所有元素都是可以配置出来，包括位置、数据来源、读写属性。并且操作员的权限可以精确到每一个查看、修改的动作，可以控制每一个控件的读写操作。于是他们希望使用Struts。Struts框架的每一个Action恰好对应一个操作，只需要自己定义Action和权限角色的关系，就可以实现行为的权限控制。但是我错误的理解了Struts的用法，我为每一个页面设计了一个Action，而不是为每一个行为设计一个Action，这样根本就无法做到他们想要的权限控制方式。他们很快发现了我的问题，于是发来了一个说明书，向我介绍Struts的正确使用方式。说明书打印出来厚厚的一本，我翻了一天，终于知道了错在什么地方。但是一大半画面已经生米煮成熟饭，再加上我的Session Bean里面的流程又是按画面来封装的，于是只能改造小部分能改造的画面，权限问题另找办法解决了。
下面就是这个系统的全貌，场面看上去还是蔚为壮观的：
