原来不知道自己想要什么，一般习惯于三层，而且还是bll简单化的三层，现在是越来越清晰的明白自己想要什么了。
简单化的三层存在的问题：
1.表驱动的，N个表，就有N*3个类。
2.业务全部被放到了界面后面隐藏的类里面去了。换界面不容易。
3.业务复杂的话，修改起来比较崩溃。比如说一个业务有5个表参加了，那么里面的业务代码长，复杂，表的关系也是复杂。绕来绕去头晕了。
修改起来也是小心异常。
原来打算使用DDD驱动，但是这个东西，首先要有业务专家，分析起来头大，水平不够就算了。所以就选用了csla.net。
最后参加了几个复杂一些的项目。我发现，我只需要这样三个东西来做业务:
1.业务类，应该是UI对应的类，而不是简单的D2O,O2D的传输类。它的属性要更符合业务字段(其实是用户接口或者叫UI)的类。比如说，文章里面有一个叫类型的属性，
两种方式，传输类，只有类型的编号，传输类，引用了类型。我想用第三种，将类型的名称也放到传输类里面，
从业务上面来看，文章本来就有一叫类型的属性，用户接口里面用的就是名称，只有程序员才知道用编号。
在有一些简单系统里面可能就只有一个叫类型的属性，它只有一个字段。
2.上下文，应该叫表达式吧。以往的编码，刚入行时，人家告诉我们说，根据名称获取某条信息，你要写...ByName,根据ID获取某条信息，你要写...ByID,
最后你要重载一个，好多参数的方法，或者是参数类的方法。所以一个BLL里面一大堆方法下来。不如一个方法。用表达式来做参数。更加清晰明了。而且一般的
表达式，你不用特殊的解析，前面UI对应的类做好了，后面的查询一般都在UI里面有了。不需要做特别的处理。有一些特别的规则，比如说，状态为true，才能用，
这个可以默到表达式里面。还有环境上下文，当前用户相关的环境上下文【数据权限、业务权限】等。
3.UI辅助类。帮助业务逻辑与UI交互，在做很多业务的时候，会有，你是否。。。。。，是，否的询问，为了这个交互，只好把业务放到了UI的后台类里面，这是正确的，
但是不好看。而且写程序不能像写文章那样，一气呵成，中间，会被这个交互打断了，【一般是从winform到webform或者是mvc的时候】。
UI的逻辑本身比较复杂。但是在业务中使用的，大体上面，只有树，树列表，列表，工具栏，下拉菜单，连动选择控件，输入限制控件，而且如果是做业务系统，UI一般，
风格比较固定，所以统一是可行的。
此时UI可以由一个人做，业务由另一个人做，统一的接口是UI辅助类。业务通过特性指定UI的类型。UI的外观，由另一个人处理，圆的按钮，方的按钮，怎么放。写到模板里。
博客园真的是让人成长，这些思维也不是乱想的，oea的UI就是这样的。csla在数据门户上体现一种，数据操作也是业务的一部分，某人写的POCO真的那么重要吗，我看到了上下文，
表达式的好处，接合csla，这个是真的可以特别的灵活。从csla上，我看到了UI和业务类的统一。以往我看oea的方式，我觉得复杂，不灵活，难用，现在，我还不会用，
但是，我觉得是用这种方式在做业务的时候真的变的简单了，以往我会被打断，这个查询没有写，赶快去BLL，DAL里面加。这个放在这不行，因为要和用户交互，没有引用到UI的框架，
然后copy,past。一个UI后台类，写到上万行，很正常。无所保证其完全正确，写单元测试，写不了，很正常。
虽然不是唯一的开发方式，但对我来说，是比较合适我的开发的。
题外话，如果不是csla和oea开源还有很多人分享他们的思路和源码，那么我现在应该积极的去做管理了，这种工作多好，
跟领导吹吹牛，侃侃大山，压力来了，分给下面的人，哪有什么压力。有功自己领，拿点汤给别人，有错，下面人的问题。