EaBIM一直以来积极响应国家“十二五”推进建筑业信息化的号召,对建筑领域的信息技术开展深入技术交流和探讨!致力于打造“BIM-建筑师-生态技术”三位一体综合资源交流共享平台,希望为BIM与可持续设计理念及技术的普及做出微小的贡献!!!

EaBIM

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 458|回复: 0
打印 上一主题 下一主题

[架构模式] 什么是事务、模式、框架

[复制链接]

1514

主题

7465

帖子

1万

积分

admin

Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10Rank: 10

积分
12404

社区QQ达人

跳转到指定楼层
楼主
发表于 2014-1-10 14:16:29 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
为了完成对数据的操作,企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
分布式访问一个单独的数据资源,以及从一个单独的应用构件访问分布式资源。
在这种情况,可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
通过一组分布式的、访问多个资源的数据的构件实现一个工作单元,和/或部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下,所有资源要把数据状态返回到以前的状态
(比如说,工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性,这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:

原子性(ATOMICITY):
一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下,构成事务的所有操作的效果必须被撤消,数据应被回滚到以前的状态。
一致性(CONSISTENCY):
一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时,数据应处于一致的状态。换句话说,一个事务应该把系统从一个一致-状态转换到另一个一致状态。举个例子,在关系数据库的情况下,
一个一致的事务将保护定义在数据上的所有完整性约束。
隔离性(ISOLATION):
在同一个环境中可能有多个事务并发执行,而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:
在一个事务执行过程中,数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。
两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
持久性(DURABILITY):
一个被完成的事务的效果应该是持久的。
现在软件设计里到处都是模式,框架。有次朋友问什么是模式?我也在学习中,就我的学习经验,给出以下小结。(注意:个人观点,仅供参考,欢迎指正。)
1.什么是模式?
模式,即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度,那就是模式。Alexander给出的经典定义是:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心。通过这种方式,你可以无数次地使用那些已有的解决方案,无需在重复相同的工作。模式有不同的领域,建筑领域有建筑模式,软件设计领域也有设计模式。当一个领域逐渐成熟的时候,自然会出现很多模式。

2.什么是框架?
框架,即framework。其实就是某种应用的半成品,就是一组组件,供你选用完成你自己的系统。简单说就是使用别人搭好的舞台,你来做表演。而且,框架一般是成熟的,不断升级的软件。
3.为什么要用模式?
因为模式是一种指导,在一个良好的指导下,有助于你完成任务,有助于你作出一个优良的设计方案,达到事半功倍的效果。而且会得到解决问题的最佳办法。
4.为什么要用框架?
因为软件系统发展到今天已经很复杂了,特别是服务器端软件,设计到的知识,内容,问题太多。在某些方面使用别人成熟的框架,就相当于让别人帮你完成一些基础工作,你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟,稳健的,他可以处理系统很多细节问题,比如,事物处理,安全性,数据流控制等问题。还有框架一般都经过很多人使用,所以结构很好,所以扩展性也很好,而且它是不断升级的,你可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台(如J2EE)和高层业务逻辑之间的中间层。
5.软件为什么要分层?
为了实现"高内聚、低耦合"。把问题划分开来各个解决,易于控制,易于延展,易于分配资源...总之好处很多啦:)。
评论:
如果说架构师是在模型图纸上工作的,那么模型元素必须是实实在在的,正如我们不可能期望抽象派画家来设计高楼大厦,没有实际意义的模型元素,是不可能构筑出软件系统的。迄今为止,绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的,这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力,目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升,但是它始终面临一个很明显的局限,那就是人的因素。人虽然在创造性方面有绝对优势,但是在精确性、持久性、效率、质量上是无法比拟机器的。所以我们希望在软件系统构建过程中,人和机器发挥各自的长处,也就是说,让人来扮演架构师的角色,而让机器来扮演程序施工者的角色。事实上,目前已经有了成功的模式了,那就是KCOM 商业工程(http: //www.kcomsoft.com)企业应用平台所采用的基于设计的全自动化软件工厂模式,采用这种模式,架构师在工具平台所提供的模型图设计环境里做软件系统的设计,设计结果由工具平台自身所带的"软件工厂"自动加工成最终企业应用软件系统。这样的开发模式,能使企业应用软件系统的开发在效率、质量上有了质的提升,从根本上区别于传统的设计模式,因为这里的设计模式已经包含在软件工厂编译器之中了。

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
工作时间:工作日的9:00-12:00/13:30-18:00,节假日不在线,请勿留言
*滑块验证:
您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|EaBIM网 ( 苏ICP备2020058923号-1  苏公网安备32011502011255号

GMT+8, 2024-11-16 12:42

Powered by Discuz! X3.2 Licensed

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表