摘要：RUP开篇之作：http://www.ibm.com/developerworks/cn/rational/r-4p1-view/index.html百科：http://baike.baidu.com/view/2930223.htm?fr=aladdin参考：http://www.ibm.com/... 阅读全文

摘要：1.http://www.cnblogs.com/wuyuegb2312/category/508153.html 阅读全文

摘要：资料：1.http://mef.codeplex.com/2.http://msdn.microsoft.com/zh-cn/library/dd460648(v=vs.110).aspx3.http://blog.csdn.net/beniao277/article/category/7066644.http://mef.codeplex.com/wikipage?title=Guide&referringTitle=Home 阅读全文

摘要：Architectural Design Method has been Extended to Method SystemPre—Architecture阶段使命：全面理解需求，从而把握需求特点，进而确定架构设计驱动力 （ADMEMS矩阵，p27）Conceptual Architecture阶段：重大需求塑造做概念架构没有风险的软件早就开发完了！错的一半是金，败的一半是贝第3章 Pre—Architecture总论：1. 工作目标： 理解需求，建立需求大局观，确定架构设计方向2. 关键需求决定架构，其余需求验证架构3. 任何需求都可以定位于业务级需求、用户级需求、开发级需求这3个层次的某一 阅读全文

摘要：对象-关系结构模式（第12章）1. 标识域（Identity Field） 定义：为了在内存对象和数据库行之间维护标识而在对象内保存的一个数据库标识域。 键选择：唯一、恒定，能快速进行相等操作、快速得到下一个键的类型（可以是单个或组合，但注意日期时间类型；可以是表唯一键，也可以是数据库唯一键，但当有表继承时需要警觉） 对象内表示方式：简单的使用整数键即可，组合的可以建立一个键类（通用类或每个对象独自对应一个类均可） 获取新键值：自动生成域、数据库计数器、GUID、键表（表名 + 下一个有效值） 使用时机：领域模型、行数据入口 2. 外键映射 定义：外键映射把对象引用映射到数据库中的外键 使.. 阅读全文

摘要：1. 工作单元 用于维护受业务事务影响的对象列表，并协调变化的写入和并发问题的解决。如下： 1）运行机制： 关键：是提交时，决定要做什么。它打开一个事务，做所有的并发检查（使用悲观离线锁或乐观离线锁）并向数据库写入所做的修改。（开发人员根本不用显示调用数据库更新方法） 记录对象更新的方法： 调用者注册方式：用户如果改变了某个对象就必须将他注册到工作单元，任何没有注册的对象提交时都不会写入数据库。 对象注册方式：注册方法置于对象中，从数据库加载对象会将加载的对象注册为“干净”的，setting方法将要设置的对象注册为... 阅读全文

摘要：1. 表数据入口 充当数据库表访问入口的对象，一个实例处理表中所有的行。 1）运行机制： 表数据入口包含了用于访问单个表或试图的所有SQL，如选择、插入、更新、删除等。其他代码调用它的方法来实现所有与数据库的交互。 表数据入口可以和表模块一起使用，它产生一个记录集数据结构由表模块处理 2）使用时机： 数据入口特别适用于事务脚本，行数据入口和表数据入口间的选择归结于如何处理多数据行，当结果集的表现便于事务脚本处理时，用表数据入口。 3）示例： 如下2图分别是普通情况下、充分利用.net特征下的表数据入口实现： 2. 行数据... 阅读全文

摘要：1. 事务脚本 1）调用数据库：事务脚本将所有逻辑组成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封存器。 2）脚本处理：每个事务都有自己的事务脚本，尽管事务间的公共子任务可以被分解成多个子程序。 3）运行机制： 事务脚本应该置于与其他处理表现层和数据源层的类相独立的类中，把事务脚本组织成类的两种方法： a. 将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起； b. 使用Command模式，每一个事务脚本对应一个类 (command) 4）使用时机: 业务逻辑简单场景（同时注意谨慎提取公共子程序以... 阅读全文

摘要：建议：即使对XP不感兴趣，也应该认真地思考三个方面的技术实践：持续集成、驱动测试开发和重构1. 从领域层开始 1）事务脚本模式最简单，适合于在关系数据库之上构建；领域模型需要非常专业的技术，还有鱼数据库的连接；表模块模式折中，在.Net这类有非常强大记录集支持的环境非常合适 2）理论上，可以根据架构来选取工具；实践中，可以让架构和工具相匹配 2. 深入到数据源层 1）事务脚本的数据源： 可供选择的数据库模式为：行数据入口和表数据入口，两者之间选哪个取决于实现平台的方便以及系统未来的发展方向（如：开发平台所包含的工具，比如支持记录集合工具） 2）表模块的数据源： ... 阅读全文

摘要：1. 分布对象的诱惑： 中间件的对象分布对上层透明崔然非常有用，但跨进程、跨机器（还有网络）调用，影响性能！ 2. 远程接口和本地接口： 1）远程访问的对象需要使用粗粒度接口，而本地访问的对象需要使用细粒度接口（优化性能时，本地接扣可以提供粗粒度对象） 2）基于1），就不能把在单进程中设计的类原封不动地搬到分布模型环境中 3）分布对象设计第一定律：不要分布使用对象！ 4）怎样有效利用多处理器资源：使用集群系统（在每个处理器上都部署所有对象，每个处理器上的对象都只需要用到本地调用 -> 运行更快，还可以使用细粒度接口设计对象模型） 3. 必须使用分布的情况 ... 阅读全文

摘要：1. 无状态的价值： 无状态可以仅用很少的对象就可以处理很多的用户，空闲状态的用户越多，无状态服务器就越有用 2. 会话状态： 相关性：会话状态只与当前会话有关，它存在于业务事务中，与其他会话及他们的业务事务是分开的； 与记录数据信息的区别：记录数据时长期保存在数据库中的持久化数据，它对所有会话可见，会话状态需要提交成为数据库中的记录； 最大问题：出现在处理隔离性的时候（同时操作，或者相关联操作） 不能把会话中所有数据都看成是会话状态 3. 存储会话状态的方法： 1）存储会话状态的3种方法： 客户会话状态：在客户端保存数据（在web中可用url、cookie、... 阅读全文

摘要：离线并发：多个数据库事务中支持多线程的各种应用服务器1. 并发问题： 1）丢失更新（同时编辑文件，相继保存，最终丢失先保存者更新的内容） 2）不一致性（读取期间，数据有更新） 2. 执行语境： 1）从与外界交互角度看的2个语境： 请求：对应于软件工作的外部环境发出的单个调用，处理请求的软件会决定是否返回一个应答（过程大部分是在服务器端进行，而客户端则假设为在等待应答） 会话：客户端和服务器端之间一次长时间的交互 2）操作系统的2个语境： 进程：重量级的执行语境，将其正在处理的内部数据域外部隔离开（有效隔离，减少冲突，但需要消耗很多资源） ... 阅读全文

摘要：构建web服务器上应用程序的2种方法： 1）使用脚本：CGI、Java Servlet，通过write stream操作输出字符串；适合于解释请求消息 2）使用服务器页面：把程序和返回文本也组合在一起，在html中编写返回页面（Asp、php、jsp等）；适合于格式化应答消息1. 视图模式： 1）转换视图： 特点：使用程序的一种转换风格（如XSLT) 2）模板视图： 特点：允许你在网页结构中编写表现层，并允许在网页中嵌入标签，用以知名网页中动态内容需要导向到哪里（如ASP、JSP、PHP等） 优点：提供强大功能、灵活 缺点：代码混乱以至于难以... 阅读全文

摘要：关系数据库之所以取得成功，最重要的原因之一就是SQL的存在，它是数据库通信标准语言。1. 架构模式： 驱动领域逻辑访问数据的方式： SQL语句嵌入在程序设计语言中； 行数据入口、表数据入口：把SQL访问从领域逻辑中分离出来，并把它放到独立的类中（让它们以数据库中的表结构为基础，每一个数据表对应一个类），这些类为数据库建立了一个入口； 活动记录：领域模型简单时，每个领域对象负责对应数据库的表的存取过程 数据映射器：领域模型复杂时，处理数据库和领域模型之间的所有存取操作，并且允许双方都能独立变化 面向对象数据库：领域模型不管有多复杂，均可使用（... 阅读全文

摘要：1. 模型抉择： 1）领域逻辑复杂度： 2）抉择： 领域逻辑复杂度较低时，选择事物脚本； 如果开发环境拥有大量基于记录集的工具（.Net和VS），可以选择表模块； 开发小组经验丰富时，选择领域模型； 3种模式并不互相排斥，可以同时使用2. 服务层： 1）服务层是从领域层分离出来的，用于置于底层的领域模型或表模块之上 2）服务层用于放置事物控制和安全等功能 3）如果确实需要，服务层尽可能最小化（充当于一个Facade层） 阅读全文

摘要：1. 分层优缺点： 1）优点： 在无需过多了解其他层次的基础上，可以将某一层作为一个有机整体来理解； 可以替换某层的具体实现，只要前后提供的服务相同即可； 可以将层次间的依赖性减到最低； 分层有利于标准化工作； 一旦构建好了某一层次，就可以用它为很多上层服务提供支持 2）缺点： 层次并不能封装所有东西，有时会带来级联修改； 过多层次会影响性能； 决定建立那些层次以及每一层的职责是什么难以决定2. 企业应用中层次的演化： C/S（领域逻辑放在客户端） -> 领域逻辑放到数据库，作为存储过程 -> 三层架构... 阅读全文

摘要：1. 架构： 最高层次的系统分解、系统中不易改变的决定（有些主观）2. 企业应用特点： 持久化数据、涉及到大量数据、很多人同时访问数据、大量操作数据的用户界面屏幕、需要与散布在企业周围的其他企业应用集成、可能会遇到业务过程中的差异以及数据中概念的不一致性、复杂业务无逻辑3. 企业应用分类： 选择架构时，必须很清楚地了解面临的问题，在理解的基础上再来选择合适的设计。同时，即便选择了某种模式，也需要进一步根据面临的问题来修改模式 在系统开发时应该选取尽可能少的工具，注意不同的工具擅长处理的方面不同，切记不要用错工具4. 关于性能的考虑： 性能：响应时间、响应性、等待时间、吞吐率、负载（当前有多少用 阅读全文

摘要：1. 面向对象最大优点在于它能够使复杂逻辑易于处理2. 阅读本书方法：从头到尾将第一部分的叙述性章节读完，然后再根据兴趣和需求翻阅第二部分的有关章节3. 软件架构通用性书籍：POSA（面向模式的软件架构）4. 迭代开发的核心在于只要软件对用户有用，就应当交付，即使这个软件当时并没有完成 阅读全文

摘要：1. 何为领域驱动设计： 怎么让软件和领域和谐相处：最佳的方式是让软件成为领域的反射（映射），体现领域里重要的核心概念和元素，并精确实现它们之间的关系。 领域模型不是一副具体的图，它是那幅图要极力去传达的那个思想！2. 通用语言： 由软件架构师、开发人员和领域专家构成的开发团队，需要一种语言来统一他们的行动，以帮助他们创建一个模型，并使用代码来表现模型。 一个明智的沟通模型的方式是创建一些小的图，让每副小图包含模型的一个子集。这些图会包含若干类以及它们之间的关系，然后向图中添加文本，文本将解释图所不能表现的行为和约束。3. 模型驱动设计： 紧密关联领域建模和设计，模型在创建... 阅读全文

摘要：1. 数据访问层究竟是什么： 1）功能需求： 数据库独立性（无论最终的数据存储介质是什么，数据访问层都要能为系统的其他部分提供同样的服务） 像插件一样可配置（将数据库访问层作为一个黑盒，该黑盒提供了一个固定接口，并从配置文件中动态读取出当前数据访问层组建的细节）：接口、ORM 2）数据访问层的职责： CRUD、Query、Transaction Management、Concurrency 3）关系： 架构图如下： 数据访问层和领域模型并不直接通信，而是靠服务层来协调，这事架构上的关键之处。2. 设计数据访问层： 分离接口模... 阅读全文