您的位置:首页 > 其它

所思所想 业务逻辑

2015-01-26 09:31 288 查看
1.在一次的操作中不要涉及到过多的数据表,数据表过多---导致编码复杂,易出错,这样就是在一个方法中做了很多的事情

2.业务规则对应着业务方法

3.现在关注一下数据,我们在页面上看到的所有东西都是数据,那么如何将这些数据抽象成为你想要的对象呢?

4.尽情放开你的思想,你随便可以创造任何的对象,没有对错之分,在你的世界里你就是主宰,你想怎么操作就怎么操作
所以请不要约束你的思想,尽情的构造你自己所认为的对象世界

5.要有一个概念”用户交互“”使用场景“”交互过程“,在这个分析互动的过程中可以看清楚很多的问题

6.我们先要脱离数据访问层,直接在业务层,在系统中看待业务对象,不要使数据库的设计影响我们对系统的实现

7.不能根据数据库model来决定你的业务对象,业务中要使用什么对象完全是具体业务所决定的

8.原来架构是针对业务逻辑来说的

9.业务逻辑决定着你的数据库设计,它是一个上层的东西

10.从数据库上可以推测出你的系统业务逻辑

11.数据库的设计是一个底层的东西,归属于业务逻辑,不要本末倒置

12.要学会画出系统对象业务交互图

13.数据库中的表对象不等于业务对象这一点要注意

14.VO和DTO差不多说的是同一个东西

15.所谓的ORM其实就是将数据库中的对象进行建模放在程序对象中去使用

16.对象交互的消息模型是OOP更为本质的特征

17.消息关注的是对象间的接口和交互,在构建大的系统的时候重要的不是对象/模块的内部状态,而是它们的交互

18.封装是划分了基于类的静态的代码边界,使得类的private代码修改不影响外界,而不是对于动态对象的保护

19.常见的一些实体 分类和产品 品牌和分类

20.我们可以关注一些微软内部类对象的封装过程,我想这些大师的设计 应该是非常高明的

21.和使用火车头是一个道理,应该更多的去使用,才能灵活的变通起来

22.按照需要定义你的对象
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: