公司网站怎么设计,中企动力做网站多少钱,小众软件,学做西餐的网站原来不知道自己想要什么#xff0c;一般习惯于三层#xff0c;而且还是bll简单化的三层#xff0c;现在是越来越清晰的明白自己想要什么了。 简单化的三层存在的问题#xff1a; 1.表驱动的#xff0c;N个表#xff0c;就有N*3个类。 2.业务全部被放到了界面后面隐藏的类…原来不知道自己想要什么一般习惯于三层而且还是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的方式我觉得复杂不灵活难用现在我还不会用 但是我觉得是用这种方式在做业务的时候真的变的简单了以往我会被打断这个查询没有写赶快去BLLDAL里面加。这个放在这不行因为要和用户交互没有引用到UI的框架 然后copy,past。一个UI后台类写到上万行很正常。无所保证其完全正确写单元测试写不了很正常。 虽然不是唯一的开发方式但对我来说是比较合适我的开发的。 题外话如果不是csla和oea开源还有很多人分享他们的思路和源码那么我现在应该积极的去做管理了这种工作多好 跟领导吹吹牛侃侃大山压力来了分给下面的人哪有什么压力。有功自己领拿点汤给别人有错下面人的问题。转载于:https://www.cnblogs.com/forhell/archive/2013/05/25/3098521.html
