领域逻辑组织

　　

领域逻辑组织能够分为三种主要的模式：事务脚本(Transaction Script)、领域模型(Domain Model)和表模块(Table Module)”

　　事务脚本 Transaction Script

　　使用过程来组织业务逻辑，每一个过程处理来自表现层的单个请求。大多数应用均可以被看做是一系列事务。一个事务可能将某种信息看做是以特定方式组织的，而后另外一事务则会改变它。在客户系统和服务器系统这间的每次交互都包含必定数量的逻辑。它可能如显示数据库中的信息那般简单。蛤在其余一些状况下，它可能涉及许多校验和计算的步骤。事务脚本将全部这些逻辑组成成单个过程，在过程当中直接调用数据库，或者只经过一个简单的数据库封装器。每一个事务都有本身的事务脚本，尽管事务间的公共子任务能够被分解成多个子程序。

　　事务脚本组织成类的方法

　　将数个事务脚本放在一个类中，每一个类围绕一个主题将相关的事务脚本组织在一块儿。(最经常使用)

　　每个事务脚本对应一个类，此时需使用命令(Command)模式。使用时机

　　事务脚本胜在简单。对于只有少许逻辑的应用程序来讲，使用这一模式很是天然，不管在性能上仍是理解上都不会带来太大开销。

　　当业务逻辑愈来愈复杂时，该模式就会愈来愈难以保持良好的设计。它特有的问题是事务之间的冗余代码。

　　领域模型 Domain Model)

　　合并了行为和数据的领域的对象模型。在应用程序中使用领域模型须要创建一个完整的由对象组成的层，来对目标业务领域建模。 你会发现其中有的对象模拟业务活动中的数据，有的对象捕捉业务使用的规则。数据和处理通常整合在一块儿，从而使得数据和数据之上的操做紧密聚合。

　　面向对象的领域模型一般看起来与数据库模型相似，但仍有许多不一样之处。领域模型混合数据和处理过程，拥有多值和复杂的的关联网，而且使用继承。

　　领域模型衍生出两种风格。简单领域模型看起来与数据库设计很相似，这种设计中几乎每个数据库表都与一个领域对象对应。而复杂领域模型则与数据库 设计不一样，它使用继承、策略和其余设计模式，是一张由互联的细粒度对象组成的复杂网络，复杂的领域模型更适合于复杂的逻辑，但它于数据库的映射比较 困难。

　　因为业务行为是常常变化的。所以易于修改、建造和测试对领域层来讲十分重要。于是，领域模型与系统中的其余层之间的耦合度应达到最小。许多的分层 模式，它们的主导思想就是领域模型与系统中其余部分间保持尽量小的依赖

　　使用时机

　　什么时候使用这一模型彻底取决于系统中的行为复杂程度。若是你的业务规则复杂多变，涉及检验、计算、衍生，你就应该利用对象模型进行处理， 反之，若是你只有一些简单的判空值和少许的求和计算，事务脚本是一个更佳的选择。

　　影响选择的因素之一是开发小组灵活运用领域对象的程度。学会如何使用领域模型是极为重要的，故而出现了许多”理论体系迁移?方面的文章，它们都是关于 对象使用的。要熟悉领域模型须要实践和训练，可是一旦掌握了它，我发现处理解决最简单的问题外，不多会有人再使用事务脚本。

　　使用领域模型时，你可能会考虑设立一个服务层，以便给领域模型一个更清晰的API。

　　表模块 Table Module

　　表模块以一个类对应数据库中的一个表来组织领域逻辑，并且使用单一的类实例来包含将对数据进行的程序种操做程序。

　　使用时机

　　最常使用这一模式的场合是在Microsoft的COM设计方案中。在COM(及.net)中，记录集是应用程序的主要数据仓库。ADO 库提供了良好的机制，可供你以记录集的方式来 存取关系数据库中的数据。

　　如需采纳请联系博主.qq23728后面本身想法。