假如我是海洋
我对金色海洋的“框架”的最大批评是它的紧耦合。有没有可能即便捷、又松耦合呢？
先整理下海洋的目前需求：
（1） 尽量用鼠标拖拉，操作尽量简单
（2） 要集成权限管理，不同的权限看到的项不一样，能进行的操作也不一样
（3） 要集成验证
（4） 要有一个TreeView类似的控制板
（5） 要有一个List模式的项列表，要有分页
（6） 要有一个DetailList或FormView模式的单项查看、修改、插入的东东
（7） 强大的搜索选择框
（8） 客户需求发生变化了，要能够很方便的更改
在此基础上我再加几条：
（1） 要松耦合
（2） 要分层
假如我是海洋，我会这样设计这个系统。纸上谈兵，莫怪，没时间编码，我没那么复杂的需求，现有Asp.Net控件已经够我用了，我也没动力去编码实现。
系统结构：
系统分为四大View，要自己开发，与现有的那些Asp.Net 的View类似。具体功能在后面描述、
职责划分：
（1） Filter 负责权限控制。这个权限控制，分三方面：
a) 控制ListView中显示那些条，不同人看到的条数不一样，这是第一步过滤
b) 控制实体属性对用户的可见性，这是第二步过滤
c) 控制用户的行为，过滤四大View的几个标准行为
（2） DataSource负责提供数据和标准行为，DataSource的另一个责任是为IDE提供实体的元数据，这样方便IDE生成View部分的代码
（3） View就是显示了
（4） Database，linq2sql就不说了
下面说四大View：
（1） Dynamic View
这个类似于FormView，只是可以根据Filter动态生成。实质上就是一个FormView加上一步遍历Filter，找到那些没有授权的属性对应的子控件，把它从DynamicView中去掉。
（2） ListView
这个也就是现有的ListView加上一个Filter。
（3） TreeView
得新开发一个。设计一种树型数据结构的标准接口，然后再用Filter过滤节点，最后生成UI端的可见界面。
（4） SearchOptionsView
这个数据源就是实体类，根据Filter显示给用户一些可填项。然后动态的构造查询表达式。（貌似用linq有些困难，不熟悉linq，可能这里有点技术风险，实在不行，可以用上动态编译技术）。
下面来看看需求的实现情况：
l 尽量用鼠标拖拉，操作尽量简单: 数据库建模->biu的一下就生成数据库了->VS里拖一下，biu的一下就生成linq层了，然后拖DataSource,拖View，biu的一下又生成了。Filter也可完全由数据库权限表来生成。上面控件，全部都可以biu的一下生成。
l 要集成权限管理，不同的权限看到的项不一样，能进行的操作也不一样: Filter来负责
l 要集成验证:这个前面没讲，看加到哪一步吧，或者直接在实体上配置属性。
l 要有一个TreeView类似的控制板:有了
l 要有一个List模式的项列表，要有分页:有了
l 要有一个DetailList或FormView模式的单项查看、修改、插入的东东:可以
l 强大的搜索选择框:可以
l 客户需求发生变化了，要能够很方便的更改
加字段—写条sql语句，扔进数据库；给实体类加个属性，匹配一下，搞定；
删字段—改数据库，改实体类
改字段名字—该实体类的属性
……
l 要松耦合:是
l 要分层:是
几点评价：
（1） 对比金色海洋的原架构可能略微复杂一点点，仅靠鼠标也基本可以完成主要操作，但弹性要大太多太多了。各大View可以想怎么玩就怎么玩，而原架构UI层的限制性过大。
（2） 解耦比较彻底，分层比较清晰，这好处谁用谁知道啊。并且，这样解耦和分层，并不会增加什么工作量。都是 biubiubiu的就搞定了。（奥特曼！）
（3） 职责清晰，好维护
（4） 数据分离——数据库就是数据库，元数据就是元数据，UI数据就是UI数据，不混在一起，这样，搞什么不同语言的版本也好，搞什么别的花样也好，都留够了足够的空间
（5）4大View也可以分开用，适用性广了很多
那么，四大View之间关系怎么协调呢？写几个Mediator，实现最常用的几个场景即可。
上面这些话说起来轻巧，实现起来可不轻巧。:P