企业软件架构期末考试重点分析.doc

将系统按照层次分解的好处与缺陷？ 答：好处：1在无需过多了解其它层次的基础上，可以将某一层作为一个有机整体来理解。 2可以替换某层的具体实现，只要前后提供的服务相同即可。 3可以将层次间的依赖性降到最低。 4分层有利于标准化的工作。 5一旦构建好了某一层次，就可以用它为很多上层服务提供支持。 缺陷：1层次并不能封装所有东西。 2过多的层次会影响性能。 三个基本层次的职责是什么？ 答：表现层：提供服务，显示信息（例如在windows或HTML页面中，处理用户请求（鼠标点击，键盘敲击等），HTTP请求，命令行调用，批处理API） 领域层：逻辑，系统中真正的核心。 数据源层：与数据库，消息系统，事务管理器及其他软件包通信。 对不同的领域逻辑组织方式，领域逻辑的复杂度与工作量之间的关系示意图。 答： 单表继承的优点： 1在数据库中只需要关注一个表。 2获取数据时不必进行连接操作。 3任何对继承层次的重构（比如将一个域上移至超类或下移至子类）都不需要修改数据库。 面向对象的高级准则： 1）、单一职责原则。就一个类而言，应该仅有一个引起它变化的原因； 、里氏替换原则。子类必须能够替换掉他们的基类； 、依赖倒置原则。要依赖于抽象，不要依赖于具体； 、迪米特法则。最少知识原则，一个对象应当对其他对象有尽可能少的了解； 、开放封闭原则。软件实体应该对扩展开放，而对修改封闭，是所有面向对象原则的核心； 、接口隔离原则。使用多个专门的接口比使用单一的总接口要好。 填空题与判断题 关于依赖性的普遍原则：领域层和数据源层绝对不要依赖于表现层。【判断】 在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分相关逻辑。 处理领域逻辑的常见方法是将领域层再细分成两层。服务层独立出来，置于底层的领域模型或表模块之上。通常只有使用领域模型或表模块时才会这样细分，因为仅使用事务脚本的领域层并不复杂，没有必要再单独设服务层。 表数据入口与记录集非常匹配，这使得它们成为使用表模块的当然选择。【判断】 这里控制器处理请求消息，模型负责领域逻辑，视图基于模型创建应答消息。【填空】 事务脚本胜在简单。对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大的开销。但是当业务逻辑越来越复杂时，使用这一模式就会越来越难以保持良好的设计。 如果你的业务规则复杂多变，涉及校验，计算，衍生，你就应该利用对象模型进行处理。反之，如果你只有一些简单的判空值和少量的求和计算，事务脚本会是一个更佳的选择。 表模块并没有给你提供完全的面向对象的能力来组织复杂的领域逻辑。 通过一个服务层来定义应用程序边界，在服务层中建立一组可用的操作集合，并在每个操作内部协调应用程序的响应。 服务层定义了应用的边界和从接口客户层角度所能看到的可用操作集。它封装了应用的业务逻辑，事务控制及其操作实现中的响应协调。 通常表数据入口和领域模型很少一起使用，因为数据映射器更好的分离了领域模型和数据库。 同行数据入口一样，表数据入口特别适用于事务脚本。【判断】 行数据入口和活动记录之间的区别，这个问题的关键要看是否存在任何领域逻辑。如果存在，则是活动记录。行数据入口仅包含数据库访逻辑而没有领域逻辑。 使用数据映射器的主要时机是数据库方案和对象模型需要彼此独立演变的时候。最常见的情况是和领域模型一起使用。数据映射器的主要优点是无论是在设计阶段，开发阶段，还是测试阶段，在领域模型上操作时可以不考虑数据库。领域对象对数据库的结构一无所知，因为所有这些对应关系都由数据映射器完成。【理解】 为了能正常工作，健值应该是唯一的；为了能很好地工作，健值又应该是恒定不变的。 关联表映射的标准情况就是一个多对多关联关系。 依赖映射的基本思想是在数据库持久化时，数据库中的某个类（依赖者）依赖于其他类（所有者）。每个依赖者有且只能有一个所有者。 要使用依赖映射，需要满足一些前置条件： 1每个依赖者必须恰好有一个所有者。 2不能有任何除所有者之外的对象拥有对依赖者的引用。 对于一个类层次，并不是只能使用一个继承映射模式。 从具体映射器读取数据的时候不需要连接操作。 我再三强调：“远程外观没有领域逻辑。”【判断】 当你需要在一个方法调用中在两个进程之间传输多个数据项时，应使用数据传输对象模式。