`
qinysong
  • 浏览: 193729 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论
我的论坛
粗浅的回答一下,不保证都对 1> 事务操作 是不是都是只 数据库事务操作? 事务指的是一个操作集合,具有ACID特性,其中之一就是原子性,即集合中的操作要么全部完成要么全部不完成。所以事务操作不仅只有数据库操作,在一定的需求下,一个完整的事务可能还包括一些其他类型的操作,比如发送消息、发送邮件、过程调用等。 2> 如果使用EJB的事务,那么是不是必须使用EJB的 那个 entity bean 才行? 会话Bean是支持事务的,包括容器管理事务和Bean管理事务两种。(你说的“第2个的问题属于没有答案的那种”,不知道你是什么意思,是不是我理解错了) 3> 如果使用spri ...
几种结构型设计模式的对比 各种结构型设计模式由于或是采用类继承机制、或是采用对象组合方式实现,所以很多都具有一定的相似性,下面对比较相似的四组模式进行讨论 1、适配器Adapter VS 组合Composite 相似点:都为客户提 ...
在Gof设计模式中,对设计模式的主要分类为:1)创建型、2)结构型、3)行为型。创建型设计模式抽象了对象的实例化过程;结构型设计模式涉及到如何组合类和对象以获得更大的结构;行为型设计模式描述算法和对象间职责的分配。   那么,结构型设计模式到底如何对类和对象进行组合,以获得更大的结构,组合的指引是什么呢?Adapter/Bridge/…/Proxy七种模式只是结构型设计模式的七个实例,这七个实例的核心主题是什么呢? 通过分析,我觉得可以将结构型设计模式的主题用三个词概括:1)统一、2)概括、和3)分离。   1)统一:达到一致 “统一”描述了对象组合的一个主题,通过统一性便于客户使用和扩展,在G ...
估计是程序问题,查一下访问条件有没有缓存或冲突
先不要限定于设计模式,用重构的思路,一点一点分离封装,分离差异,封装相似,最后达到每个业务方法中只含有几行操作方法的调用。 如果还可以细化设计的话可以将通用操作下移。
小几十万条数据并不算多,如果数据库设计范式级别较高,采用左外联且联接字段为主/外键或索引的话,性能应该也没有问题,且并不会造成千万的纪录数量。 从直觉来说,用户一次操作要进行这样的几百次执行,我感觉这可能是最有优化空间的地方。 当然我只是估计,因为你给的信息还是很少
其实我们的理解可能都没有什么错误,我只是表达对于Gof《设计模式》中3.3节将标题列为Factory Method —— 对象创建型模式 的自己的理解和看法,如果对这一标题你有更明晰的看法,可能就是我们这个帖子最好的收尾
我上面所指的Decorator,不是为了引入Decorator模式,只是为了增加一个和Manipulator平行的兄弟类,比如这个类可以为Figure添加颜色,修饰边框等等,这样Figure就可以把创建这些对象的工作移到抽象工厂中,但是当这种平行的兄弟类型比较少时,比如只有一个Manipulator,所以可以合并到Figure类中以简化设计。
geradle 写道唉,没有人说Java的Iterator是对象模式呀? Iterator本身就是另外一种模式啦。 你举的场景二和场景三不是一样的么。 我觉得你没有看我的回复,或者我没有说清楚吧 我列举的场景三,并不是说明Iterator模式,而是集合类中产生Iterator的工厂方法,是Factory Method模式; 场景二和场景三是一样的,而且我的观点是在这两种场景中,将Factory Method用对象创建型模式理解更好; 我很仔细的看了你的回复,你的观点是在这些使用场景中都说明Factory Method是类模式,并通过和Abstract Factory作比较说明这一观点。 这 ...
为了增强对比直观性,我把上面三种场景应用的结构图贴上来 场景应用一:文档应用框架下的结构图 场景应用二:Figure图形处理应用下的结构图 场景应用一:jdk集合迭代器的结构图
Global site tag (gtag.js) - Google Analytics