软件系统架构设计讨论

majin_com 2005-11-07 07:04:55
技术架构说明书
1 前言
一个企业级的商业软件能够满足用户需要、正常运行、易于维护、易于扩展,必须拥有一个良好的软件架构支撑。本文主要是分析和构建一个企业级商业软件架构。

2 架构分析
企业级的商业软件架构在技术层面的要求主要体系在高性能、健壮性和低成本。

 高性能
对于企业级商业软件来说,软件架构需要尽可能地使软件具有最高的性能,支持最大的并发性。
对于企业级应用,传统的最高性能的软件架构是Sun较早提出的J2EE架构方案。他通过可缩放性――一个应用在给定相应硬件的条件下支持增加的负载的潜力。简单的说,利用J2EE的分布式特性,使软件可以通过添加服务器等硬件设备来提高性能,增加负载能力。
J2EE为实现分布式体系结构提供了出色的支持。同一个分布式J2EE应用的构件可以被分布给运行在一台或多台物理服务器上的多个JVM。分布式J2EE应用以使用具有远程接口的EJB作为基础,而远程接口能够让应用服务器隐藏掉分布式构建的访问和管理的大部分复杂性。
不过尽管J2EE很大的降低了分布式应用的复杂性,但是分布式应用还是很复杂,如果通过分布式来为软件提供可缩放性,代价还是很大的。
我们现在的企业级商业软件迫切需要分布式吗?我们需要怎样的分布式?
现在企业级商业软件的性能主要在由Web容器服务器、逻辑处理服务器和数据库服务器来决定。J2EE实现的分布式体系结构主要是针对逻辑处理服务器。
下面我们分析一下逻辑处理服务器的分布式方案。逻辑处理器采用分布式的话,那么服务器的CPU颗数需要大概70颗以上。因为如果需要大概64颗CPU服务器的话,采用一台多CPU服务器就可以解决。而70颗CPU的逻辑处理服务器的硬件成本已经到了远远超出了目前商业需求所能承担的硬件成本,而且这还不包括想匹配的Web容器服务器和数据库服务器成本。所以如果需要使软件具有可缩放性,通过硬件解决方案(多CPU服务器)比软件解决(分布式系统)要有效得多。
所以就目前的商业需求和硬件环境,架构通过缩放性使得软件获得高性能,缩放性主要通过改善硬件配置来解决。


 健壮性
企业级的商业软件要求软件是可靠的和无缺陷的。现在的架构一般是,服务器模式的。软件的可靠和健壮主要依赖与服务器。服务器的稳定通过良好的代码和完备的测试能够解决这个问题。
由于客户需要,现在需要在客户端也具有一定的健壮性。当服务器由于意外出现故障的时候,客户端也能够继续运行,在客户端发生的数据先保存在服务器,待服务器恢复完备后,再把数据上传到服务器。
对于这点要求,Sun提出的J2EE架构已经事先考虑过,Sun认为软件不仅能够响应浏览器的请求,还能够响应应用服务器的请求,比如Swing编写的应用程序,VB编写的应用程序等。
所以对于健壮性要求而言,一是通过加强代码质量,二是在软件架构上采用兼容应用程序客户端的方案。


 低成本
企业级商业软件还有一个很重要的要求:低成本。软件架构要求简单、易掌握,复杂度低,易于维护和扩展,易于测试。
低成本、高效率的研发架构传统思路是采用分层的思路、OO设计原理、强调重用来。
采用分层的思路是通过把复杂的业务分块来实现降低难度,同时通过业务分拆来达到重用的目的。
采用OO设计原理能够使复杂的系统变得简单化、条理化,使开发、维护变得简单。
通过重用,可以减少开发量,减少出错的概率,易于开发和维护。

一般来说,传统的分层思路是把系统分为界面展示层,控制层,逻辑处理层,数据访问层和数据存储层。OO的设计原理主要是为了降低逻辑处理层的复杂度。
分层是为了把复杂度分解,不过多层次本身也带来了一些额外的复杂性。因此本架构设计分为三层:界面展示层、控制层和数据存储层。取消逻辑处理层和数据访问层。这样做的目的是通过降低系统架构层次来降低开发工作量。整个数据架构以XML为核心,通过XML连接所有的组件层,通过XML进行通讯。把逻辑处理放到数据存储层,通过数据库的处理能力来解决商业逻辑,这样做即可以减少开发量,也可以取消逻辑处理层,同时也可以使用OO设计进行业务处理。由于采用XML为数据为接口,所以数据访问层全部可以采用统一的模式,因此可以取消此数据访问层。


3 架构定义
本架构以XML为整个系统的交互接口,包括系统架构内部和外部。整个系统分为界面展示层,流程控制层和数据存储层。系统由架构支撑组件类、独立客户端组件类、AJAX组件类、流程控制组件类、数据存储组件类、消息组件类、邮件组件类、移动组件类、GIS组件类。
架构的核心优势是以AJAX实现最强大的浏览器客户端,以智能客户端实现独立客户端体现最强大的系统健壮性,摒弃O/R Mapping使研发效率得到大幅度提高。

...全文
1670 12 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
wind_rain 2005-12-21
  • 打赏
  • 举报
回复
基本还可以
litengda 2005-12-21
  • 打赏
  • 举报
回复
这种系统能设计成功!并开发出来的人!可以去IBM应聘架构师了
asiaec 2005-12-16
  • 打赏
  • 举报
回复
非常赞对ejb的评论!
weiyidress 2005-12-01
  • 打赏
  • 举报
回复
开发工具JavaFast
简介
什么是JavaFast
JavaFast是一个自动化的代码生成器。它让开发人员快速的开发出数据库操作程序。只需按数据库结构无需任何编码,自动生成原代码, 那些代码是可以运行通过的,不需要任何调试 ,这样就保证的调试速度, 然后你只需要在生成的代码基础上作些界面调整,来满足你的业务需求就可以了 ,这样JavaFast可以提高开发效率数5倍以上。

优点
1>提高开发速度 。
2>自动生成大部分代码,只需要作相应简单的调整就可以满足自己的业务逻辑。
3>给所有员工统一了开发规范,统一编码风格。
4>本软件目前有3个版本类型,第一个版本是纯jsp,第二个版本是jsp+javaBean,第三个版本是jstl+Spring+ibatis。
5>降低了开发成本,一个人可以相当于4个人的开发速度。
6>降低了开发风险,生成的代码规范、格式和样式都一致,以后维护程序的工作量也很小,并且不同人之间的工作可以很方便相互移交,只要知道模块业务逻辑就可以交叉修改代码
定制开发工具
如果公司有自己的一套开发框架和模式,那我也可以为你们开发一套适合自己的开发工具,可以提高四倍开发速度,在开发过程中让所有员工自觉地遵守规范和标准是很困难的,所以他有助于让员工不自觉的统一了开发规范,统一编码风格

wuhanchenjing@hotmail.com或者电话027-63176530QQ号码54624010联系
bruce_wang 2005-11-25
  • 打赏
  • 举报
回复
好乱
cm22479166 2005-11-25
  • 打赏
  • 举报
回复
恩,虽然写了很多,但看的很累.你重新组织一下再讨论吧.而且废话太多,不实用.
nighthawk 2005-11-24
  • 打赏
  • 举报
回复
用你自己的语言重新组织一下,500字以内。估计这样就可以讨论讨论
kingofhawks 2005-11-09
  • 打赏
  • 举报
回复
看了一点没能看得下去,废话感觉太多了些...
www203 2005-11-08
  • 打赏
  • 举报
回复
加油
majin_com 2005-11-08
  • 打赏
  • 举报
回复
想和大家讨论这个技术方案是否妥当,各位高手是否有其他见解
dssaaa 2005-11-07
  • 打赏
  • 举报
回复
要讨论什么呢?
majin_com 2005-11-07
  • 打赏
  • 举报
回复

4 架构说明
4.1 架构层次图






















4.2 架构组成图




4.3 组件说明
4.3.1 智能客户端组件类
对于现在B/S软件来说,用户体验的要求是致命的。由于浏览器的原因,很难达到应用程序易用性的程度。同时,由于本身的原因,瘦客户依赖于服务器。但是,具体客户实际,需要软件有较强的健壮性,当服务器发生故障的时候,客户端依然能够运行。现在主要的厂商已经在这方面做了大量的工作,Sun主推的是Web Start,微软主推的是Smart Client,比较而言,Smart Client比较成熟、有效。系统集成Rich Client能够极大的扩展系统的能力,满足用户的需求。

智能客户端有较高的复用性




智能客户端的优点





智能客户端的商业价值



智能客户端的优势
 充分利用终端设备的优势
 能够调用Web Services
 支持在线和离线两种状态
 能够如同Web应用程序一般简单方便的部署

4.3.2 AJAX组件类
AJAX 英文Asynchronous JavaScript+XML 的缩写, 中文的意思则为“在Web上通过JavaScript, 使用异步的XML Http请求, 实现无刷新的Web界面”。

现在已经有很多成熟产品在使用此技术,比如Google的Gmail、Google Map、Google Suggestion等。



AJAX有以下内容组成
 基于标准化的XHTML和CSS
 通过DOM实现动态显示和交互
 通过XML和XSLT来进行数据交换方式获取数据
 使用JavaScript来整合以上所有的技术



AJAX设计原理
 一个可扩展的核心框架,其中为JavaScript添加很多新特性,如生存期管理、继承、多批事件处理器和接口。
 一个基础类库,提供了通用特性,如丰富的字符串操作功能,计时器和运行任务等。
 一个UI框架,可以跨浏览器实现HTML的动态行为。
 一个网络栈,用于简化对服务器的连接和对Web Services的访问。
 一个具有丰富UI功能的控件,如自动完成文本框、弹出面板、动画控件和拖放。
 一个浏览器兼容的层,用于不同的浏览器中定位不同的脚本行为。



AJAX组件图


组件说明:
(略)







4.3.3 系统支撑组件类
4.3.3.1 MVC
提供标准的MVC框架结构,良好的分层设计使系统易于开发和维护。
4.3.3.2 IoC
IoC指控制反转,通过XML文件的配置使组件不需要在运行时寻找其协作者。Spring的核心就是IoC,Struts也采用了类似的方式。本架构也是以IoC为核心,通过配置来管理类和类的调用。




4.3.3.3 AOP
AOP主要是解决系统横切关注点的问题,主要是系统级服务,如:日志、事务、安全性等。他主要由五种装备构成:
 Before装备
 Throws装备
 After装备
 Around装备
 Introduction装备
4.3.3.4 MQ
由于信息系统的数据交换具有数据量大,持续时间长,不要求同步等特点。因此在数据交换上采用消息队列能够很好的解决这个问题。

4.3.3.5 DAO
提供JDBC的抽象层,使得开发者不用再去编写同RDBMS交互、非业务功能的JDBC代码。统一处理SQL异常,统一事务控制。


4.3.3.6 Mail、移动设备、GIS等
根据具体的应用需求,还有一些特殊的扩展组件。(略)

4.4 数据库
数据库的性能占系统性能的70%~80%, 如果采用O/R Mapping, 则会影响数据库方面的性能发挥,同时如果对于分布式数据库的要求,则需要EJB来完成。如果不采用O/R Mapping的要求,则可以充分发挥数据库本事的特性,实现高效存取数据,实现分布式数据库,实现企业数据整合。









4.5 XML协议组
现在商业软件的发展核心在于建立完善的协议组,例如HL7。本系统架构的核心也是也XML协议组为核心设计的。从客户端,到服务器,到数据,XML协议组贯穿整个流程。





5 综合分析
5.1 架构流程分析
通过AJAX、 智能客户端, 实现强大的客户体验,完全摒弃以往的刷新页面的方法。 客户端将数据收集后,经过整理以XML的形式,按照统一XML协议格式提交到服务器,服务器通过相应的处理、分配和运算到数据库。数据库也以XML的形式接收,处理完成后,也以XML的形式,按照统一XML协议格式返回到服务器,到客户端。

整个架构以XML协议组为核心,通过统一的协议规定指导应用研发,整个研发的主要成本在需求分析、系统设计、编码开发和后期维护。

系统架构主要和编码开发与后期维护成本相关,本系统架构的开发以XML为核心,主要的工作在于客户端组装XML,数据库处理XML,其他的系统组件层基本上不需要开发,这样开发人员的培训主要集中与客户端技术和数据库处理的掌握,从而通过降低开发人员的级别要求和精简代码使得编码开发的成本降低到了最低。后期维护的成本与编码量和代码负责度成正比,由于代码量比较少,而且以XML协议组为基本核心,所以代码的负责度也比较低,所以整体的维护成本也很少。

由于架构采用了智能客户端技术,可以实现独立客户端的模式。如果服务器发生故障,客户端不受影响,能够继续工作,工作的数据保存在客户端,等到服务器恢复工作后,再把数据上传到服务器。



5.2 可行性分析
5.2.1 技术层面
 XML协议组
此协议组是整个系统框架的核心,他的优劣是决定系统框架的稳定度和扩展性。
此协议组的核心生命周期大概为两年。两年后,应重新投入资源,制定此协议组的第二版。

 AJAX组件类
现有组件基本能满足业务需求,但都存在两大问题:一是稳定性不够,占用资源大;二是用户体验特性有待提高。
完成此组件类的任务,需要协调、安排资源,各个产品线整理自有组件,一起协商重新制定新的组件接口并实现,在新的项目和产品中使用。

 支撑组件类
此组件类主要为新项目和新产品使用。需要投入资源来研发。

 智能客户端组件类
此组件类主要为新项目和新产品使用。需要投入新资源来完成。


5.2.2 管理层面
此架构在管理层面的风险主要在与架构的推广。架构推广的难度,一个是在于文档和培训,一个是在于核心思想的推广。

 文档和培训
由于技术的复杂性,这一块以往做得很不够。但是对于技术框架的公司层面的推广,需要克服这个难题。通过借鉴公司实施部门的经验,加强相关人员的责任心,管理力度,以及加强技术人员的配合力度来解决这个风险。
 核心思想的推广
本系统架构的核心思想有三,其中关于摒弃O/R Mapping、绑定固定数据库以提高开发效率的思想,还未得到充分认可,待需要大家一起讨论。



6 FAQ
6.1 为什么不用EJB
EJB本身是Sun公司的一个美丽谎言,对于我们目前的商业应用来说,他给我们带来了巨大的复杂度,但并没给研发带来什么好处。现在北京市公共卫生的项目的EJB主要使用的是Session Bean,这和很多使用EJB的项目一样,根本上是浪费研发成本而已。
EJB的分布式,公司的商业上用不到;缓存可以用其他很简单的方式来实现,所以EJB就是鸡肋,本系统架构摒弃。

6.2 为什么不用O/R Mapping
这个话题的争议性比较大。
O/R Mapping的产生是由于OO设计的要求,但是由于本系统以XML协议组为核心,通过XML进行各层之间的通讯,而不是通过对象,同时OO设计也可以应用XML的通讯机制,所以本系统架构放弃O/R Mapping以提高研发效率。

6.3 为什么不考虑主逻辑服务器
这个话题的争议性比较多。
主逻辑服务器主要负责商业逻辑运算。我们通过医院体系的研发经验分析,现有的信息系统的商业逻辑负责度利用SQL的能力就能够处理。由于通过数据库的逻辑处理解决商业逻辑运算,一是可以减少逻辑服务器和数据库服务器之间的数据交互,提高系统性能,二是数据库服务器的运算能力也比Java的逻辑服务器运算能力高得多,因此本架构放弃主逻辑服务器。







6.4 为什么绑定数据库
对不同数据库的支持属于商业方面的选择。系统的性能和开发成本与多数据支持成反比,如果为了保障高性能、低研发成本,就需要在多数据库支持上做一些让步。从做产品的角度考虑,应主推一种数据库,国内成熟的产品是采用的如此的商业方案(例如:用友的财务软件仅支持SQLServer,这样对企业和用户本身都是效率最高、成本最低的选择)
对于技术上来将,移植数据库,我们的产品不论如何都要投入资源。投入的资源比绑定数据库要高出很多。
同时,对于实际商业需求来说,客户给我们提供的利润还不足以使我们的研发团队使每个产品在每个主流数据库(SQLServer、DB2、Oracle、Sybase、Informix、MYSQL等)都提供完善的支持。
所以,我们的产品需要绑定数据库。

6.5 界面技术为什么叫AJAX,不叫HTC
HTC是微软提出的界面组件的一种解决方案,但此方案,微软本身并不推荐。现在技术上主流的是AJAX,微软也在推此方案,并为此方案建立了一个界面架构――Atlas,所以我们的界面组件也随主流,叫AJAX,而不是HTC。

第一部分 背景知识 第1章 应重视的价值,也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一:模型 1.2.2 焦点之二:用例 1.2.3 如果重视模型,就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案(或至少是正确方向上的一大步) 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例:层 2.3.2 另一个示例:领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务:OrderRepository+OrderNumber 5.1.4 重建持久化的实体:如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查:可选的(可能的)主动检查,必需的(和自动的)被动检查 7.2.2 所有状态(即使是错误状态)都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的,以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文,上下文,还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换,还是绑定到与基础架构有关的转换 7.3.4 精化原则:所有状态,即使是错误状态,都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类,离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射(对象关系(O/R)映射工具) 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类:基础架构模式 8.5.1 元数据映射:元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类:基础架构模式 9.5.1 元数据映射:元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能:验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例:Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录

51,397

社区成员

发帖
与我相关
我的任务
社区描述
Java相关技术讨论
javaspring bootspring cloud 技术论坛(原bbs)
社区管理员
  • Java相关社区
  • 小虚竹
  • 谙忆
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧