- 博客(41)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 设计服务层
服务层中的类应该暴漏契约。实现接口是个不错的选择。该接口可能用数据迁移对象来接收并返回数据，且选用粗粒度而不是细粒度的方法，以降低来回通信次数并提高吞吐量。为问题领域中的每个实体创建一个服务类，也可以考虑使用一个服务类。强烈建议为每个服务都暴漏一个接口。
2012-08-27 20:26:50
1487
1
原创 服务层的优势、劣势
服务层的优势除去两个层之间的耦合。降低表现层与业务层之间的通信流量。服务层的劣势简单系统的服务层或许有过度设计之嫌。Flower的第一条有关分布式对象设计的建议：不要使用分布式，除非它真正能够带来好处。
2012-08-27 20:25:46
1994
原创 何时使用服务层
一套公用的应用程序编程接口。表现层和业务逻辑层都不应该包含业务逻辑。老板=表现层、经理=服务层服务层应该用在所有有一定复杂性的应用程序中。若有多个前端且应用逻辑比较复杂，那么最好将整个应用逻辑放在同一的位置，而不是为每个应用程序接口都重新写一遍。
2012-08-27 20:24:41
1044
原创 服务的定义
服务的定义：在非技术的上下文中，一个与业务相关的操作，应用程序中的每个客户都可以重复地执行，这些客户包括用户、程序中的其他服务以及业务逻辑中的其他部分等。OASIS的定义一种允许访问一个或多个功能的机制，访问要通过规定的接口，且严格一致地按照服务描述中给出的约束和策略。服务就是对某个类进行另一层的封装。服务通常被设计成一个无状态的组件，一般来说，无状态组件的可伸缩性更好，其
2012-08-27 20:22:04
1304
原创 服务层的职责
在Fowler看来，服务层用作表现层和业务逻辑层的边界。1、服务层的目的：服务层位于两个互相不通信的逻辑层之间，使两个层能够松散耦合并有没地彼此分离的同时，仍旧可以完美的彼此通信。感悟 2、组织系统的行为：服务层将业务逻辑层中所有的细节对表现层隐藏起来。业务逻辑层中唯一需要完全和数据库细节分离的部分就是领域模型。理论上服务层应该通过数据迁移对象与表现层交互。
2012-08-27 20:19:37
1580
原创 服务层就是什么？
服务层实际上不执行任何具体的工作，其功能在于组织各个业务对象、应用程序专有的服务、工作流以及其他任何出现在业务逻辑中的特殊组件。
2012-08-27 20:18:31
2033
原创 将对象映射至数据表
领域模型模式中，执行数据库操作的代码叫做数据映射器。数据映射器模式是指使用一系列类将逻辑实体(以及其所有的关系)映射至数据表和记录(通常在关系型数据库)之上。领域模型的最重要难点：数据映射器的实现完全由手工完成。
2012-08-20 21:45:25
1351
原创 仓储模式
通常领域模型中的类包含数据和行为，不过行为仅仅用来表示实体的逻辑，不包含加载数据相关的逻辑。一般会为每个实体创建一个仓储对象。将领域实体和持久化逻辑拆分开好处：可以很容易地为仓储提取接口，随后使用工厂模式将所有数据库代码封转到一个实现了该接口的对象中。这样，领域模型即可配合任意的数据访问层以及数据提供器。仓储工厂在内部可以读取实际的类型，并根据配置文件进行实例化，这样就使整个解决方案更
2012-08-20 21:44:30
1872
原创 持久化透明
领域模型中的类型总是不会提供显式执行数据库访问的方法。领域对象中不应该包含有关持久化的代码，因为将持久化和领域逻辑这两个职责放在一起会违反单一职责原则。领域类型总是需要持久化的，真正的问题是这部分代码应该放在何处，是在领域类型中呢？还是领域类型之外呢？
2012-08-20 21:43:02
1427
原创 领域模型模式实践
和活动记录的区别：领域模型是和数据库无关。主要参与者实体、辅助的实体。避免公共逻辑的重复。可定义一个基类，包含所有的公共逻辑，并作为领域模型对象的超类型。Microsoft Enterprise Library 4.0提供了一个很不错的验证组件。领域对象中不包含任何将其状态保存至存储介质的逻辑。
2012-08-20 21:41:40
1132
原创 领域模型的优势、劣势
领域模型的优势充分利用了面向对象设计的优势。无需受到数据库结构的限制。可以很轻易的替换掉数据访问层。领域模型的劣势很难将整个系统构想成一个抽象模型。需要引入新的复杂性来处理现有复杂性。主要障碍是对象和关系型数据库之间的不匹配。不过有O/R映射工具。
2012-08-20 21:40:15
2810
原创 何时使用领域模型
何时使用领域模型？业务逻辑的重用性需求就成为判断是否值得使用领域模型的一个关键参数。复杂性是选用领域模型模式的主要动力，复杂性应该按照现有需求来衡量，不过也应该考虑到日后可能出现的增强或修改需求。
2012-08-20 21:38:50
961
原创 领域模型模式概述
领域模型模式随着系统复杂性的提高，关注数据的劣势也逐渐显露出来，因此你需要开始同时关注与数据和行为。从长远来看，以数据为中心的方法并不能很好地适应规模的增加。领域驱动设计。领域模型模式力求让对象模型与系统的概念模型匹配起来，这样的对象模型就叫做领域模型。领域模型描述了系统中涉及的实体，捕获了实体之间的关系以及数据在其中的交换过程。一系列彼此相连的对象。领域模型中的实体将成为
2012-08-20 21:37:52
1059
原创 行数据网关模式
扮演着活动记录类和物理数据库之间接口的角色。行数据网关将所有活动记录相关的数据代码封装了起来。行数据网关类仅应该包含数据库访问逻辑，而不应该包含领域逻辑。
2012-08-07 23:46:56
2090
原创 外键映射模式
设计关系型数据库的基本原则：将信息放在不同的数据表中，并使用外键来建立数据表之间的逻辑关系。如何在活动记录模型中映射外键关系呢？1、直接映射原始值，领域中则展开映射关系。Fowler建议活动记录模型尽可能地简单，也即尽可能的贴近数据库结构。2、某些框架支持外键映射模式，并能延迟加载即展开关系。外键映射模式：在引用对象中以属性的方式给出引用到的真实对象的引用即可。
2012-08-07 23:46:23
973
原创 什么是活动记录模式？
活动记录是指封装了数据库表或视图的一行的对象，对象可以包含数据和行为。活动记录对象的结构应尽可能的接近于相关联的数据表结构。活动对象中通常会包含用来执行查找的查找方法、CURD操作、验证以及领域相关的计算和检查功能。实例方法操作于当前对象；静态方法操作与数据表的所有记录。何时使用活动记录？领域逻辑不是太复杂，且与数据模型之间不需要很复杂的映射关系。活动记录的优势
2012-08-07 23:45:26
3595
原创 表模块实践
总的来说，表模块业务组件中的成员一般应该是实例成员。理由如下：1、可以根据某个查询的结果来初始化类型。2、可以实现查询对象模式。表模块并没有提供区分各个子对象的概念。表模块类在内部存放的是一个弱类型数据行的集合，而不是强类型的对象集合。业务组件关注点在于应用程序的数据，而不是用户的操作。强类型DataSet、表适配器。表数据网关模式使用表适配器作为表模块类。
2012-08-07 23:43:34
844
原创 表模块模式
为每个数据表定义一个业务组件。这个业务组件叫做表模块类。其中包含操作于该数据表上的所有代码。何时使用表模块模式？对于那些不需要太多抽象，且数据模型和对象模型之间没有太大差异的场景。表模块的优势各种IDE均为其提供了很丰富的支持，特别是VS。仅此而已？表模块的劣势不适合表述复杂的众多实体。特别是当对象模型和数据模型之间有显著差别。事务脚本和表模块的选择？
2012-08-07 23:42:31
1067
原创 静态方法和实例方法
若某个方法不需要与类中的其他成员交互，那么使用静态方法。一般而言，若某个方法或属性和类是一个整体，那么就应该是静态的。若某个方法或属性和特定的实例紧密相关，则不应该是静态的。FxCop是微软公司的一个免费静态代码分析工具。为一个方法添加过多的参数显然并不友好。
2012-08-07 23:41:25
736
原创 事务脚本实践
所有实现了事务脚本的类型都可以看做是业务组件。可以让所有的业务组件集成于一个共同的基类，这样可以确保所有的类型都有一个共有的相同基本行为。实现横切关注点：在类中定义一些成员用来存放一些外部引入的对象。每个业务组件中都可以有一个或多个事务脚本。将各个事务脚本分组，然后让每一组成为一个业务组件。另外一种做法是将每个事务脚本用单独的类封装起来，这样每个业务组件仅包含一个方法。命令对象一般
2012-08-07 23:40:00
1383
原创 事务脚本的劣势
事务脚本有造成代码重复的潜质，最终程序变成了一团混乱的子程序组合。通心粉代码。重构可以在很大程度上缓解事务脚本天生的劣势，但重构也有其范围。软件的回归测试。真正的敌人是重复，而不仅仅是代码重复。对脚本进行分组。
2012-08-07 23:39:10
1137
原创 事务脚本的优势
简单的过程式模型。对于逻辑不多、时间紧迫且依赖于强大的集成开发环境的项目，事务脚本是其理想的选择。过程式方法不意味着要编写大段、不可拆分的代码。
2012-08-07 23:38:34
1160
原创 何时使用事务脚本
适合应用于那些业务逻辑非常简明直白，且最好不大可能改变的简单场景。简易度和复杂性很难衡量。对象能让代码变得优雅，不过优雅只是代码可以正常工作之后的锦上添花。数据访问通常被封装在另一些组件中，并不属于脚本的部分。
2012-08-07 23:37:50
905
原创 事务脚本概述
关注点在于用户通过表现层所能执行的操作，并为每个操作编写一个专门的方法。这个方法就叫做一个事务脚本。事务指一个需要执行的业务流程。脚本表示我们会逻辑上将一系列系统操作与每个用户操作关联。
2012-08-07 23:37:15
848
原创 领域实体
业务对象不过是某个领域实体(即封装了数据和行为的类)的实现。业务对象包含了数据和行为，是可以参与到领域逻辑中的完整对象。数据迁移对象更像是一种值对象，即一系列数据的容器而没有相关的行为。领域实体类型可能会与多个对应的数据迁移对象。数据迁移对象仅仅是所需部分数据的投影而已。使用业务对象？还是数据迁移对象？整洁干净？还是减少类的数量？
2012-08-07 23:36:35
898
原创 对象模型和领域模型
系统设计的难点通常在于为业务创建合适的软件模型。对象模型仅仅是一系列的对象，并不包含模型在设计和实现上的约束。领域模型是一个用来实现一系列需求的对象模型。
2012-08-07 23:35:46
1172
原创 什么是业务逻辑层？
抽象地说，业务逻辑层是软件中专门处理业务相关任务性能的部分。业务层是所有分层系统的核心，包含了系统的核心逻辑。通常也叫作业务逻辑层。
2012-08-07 23:35:19
2521
原创 适用建议
若想设计出好的软件，普通的设计原则就够了，但时至今日，重复发明轮子绝对谈不上是什么好事。尽量保证简单，但不要再继续简单下去了。不要重复自己。一次且尽一次。你不会用到它。
2012-08-06 22:37:00
882
原创 从对象到方面
面向对象的理念擅长于将系统分解成组件来描述流程，也擅长于处理组件的关注点。不过对于那些横切的关注点，面向对象理念却不在行。横切关注点是指那些将会影响到系统中多个组件的关注点。面向方面编程AOP。AOP的主要目的是将横切关注点于核心关注点的实现拆分开。在AOP中，我们可以将某个横切关注点封装到一个新的组件中，该组件就叫做一个方面。方面就是一个可重用的组件，其中封装了项目中多个类型需要
2012-08-06 22:36:25
784
原创 依赖注入
用一段泛化的代码控制更加特定的外部组件的执行。若满足了里氏替换原则和开放/封闭原则，那么改变任何外部组件都不会影响高层次的方法。外部组件和高层次方法可以分开开发。依赖注入的三种实现方式1、通过被注入方法所在的类的构造函数。2、通过在被注入方法所在的类中定义一个方法或属性。3、让被注入方法所在的类实现一个接口，接口中提供了辅助组件的具体实现。
2012-08-06 22:35:18
1078
1
原创 惯用法是什么？
惯用法是一个硬式编码在编程语言或实现在框架/技术中的模式。设计模式关注的是面向对象的设计理念，惯用法关注于编程语言的技术。考虑在特定技术或平台的上下文重新评估设计中应用原则的方式，这个过程中叫做惯用设计。应该尽可能地使用类，除非类型所占的存储空间低于16字节或类型是不可变的。推荐在公开签名中使用IList或其派生接口，或者使用实现了IList接口的自定义类型。
2012-08-06 22:34:21
2466
原创 模式的真正价值是什么？
在于交付的时候解决方案是否能正常工作并满足需求。模式就是其他人已经遇到过并加以分类的问题的解决方案。重构模式的时候需要判断是否能够更好地适应未来的变化，并对当前的解决方案有所改进。软件架构师大多是关于决定的。反模式是一种介绍如何从问题演化到不好的解决方案的模式。
2012-08-06 22:33:30
816
原创 如何使用设计模式？
最合适的设计模式通常在重构的过程中渐渐浮出水面。批注 首先需要明确问题的关键，并将其一般化。然后在应用到程序的上下文中，通常会涉及代码的重构。
2012-08-06 22:31:59
734
原创 什么是设计模式？
普遍认同的2种软件模式：设计模式和架构模式。重构模式模式的定义：每个模式都描述了一个问题，这个问题在我们的环境中一遍一遍出现。且模式还给出了这个问题的核心解决方案，这个方案可以被一次次地重用，而无需每次都从头开始。
2012-08-06 22:31:23
786
原创 面向对象的高级原则
1、开放/封闭原则模块应该对扩展开放，对修改关闭。每个类型应该是固定的，不在未来有任何变化，更不要修改类型的源代码。即类型对修改关闭。每次发生变化时，要通过添加新代码来增强现有类的行为，而不是修改原有代码。可以使用如下两种方式：①用组合创建新的类型。②使用安全干净的继承体系。在类型继承中，应该仅仅添加新代码，不应该修改任何继承得到的上下文。2、里氏替换原则子类应
2012-08-06 22:30:37
1068
原创 面向对象的基本设计原则
面向对象设计的一个重要步骤是为问题领域找到一个干净灵活的抽象。此时应该考虑的是事情而不是流程，应该关注的是什么，而不是如何。找到合适对象的做法：标记出所有用例中的所有名词和动词。1、尽量降低耦合将接口和实现分离开来，将会受益良多。基于接口，而不是实现编程。2、尽量保证代码重用白盒重用、黑盒重用。继承、组合、聚合。对象组合更加安全，且易于维护和测试，只是组合无法实现多
2012-08-06 22:29:05
1129
原创 分离关注点
有助于实现软件的高内聚和低耦合。分离关注点的核心在于将系统拆分成各不相同且最好没有重叠的功能。尽可能保证模块之间没有功能上的重复。分离关注点是通过模块化代码以及大量的运用信息隐藏来实现的。模块的实现细节并不会被其他模块知晓或访问。信息隐藏也叫做封装。在面向对象的程序设计中，使用类来分离关注点。
2012-08-06 22:27:56
1303
N层研习01的测试代码
2010-10-11
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人