架构模式逻辑层模式之:表模块(Table Model)

表模块和领域模型比,有两个显著区别:

1:表模块中的类和数据库表基本一一对应,而领域模型则无此要求;

2:表模块中的类的对象处理表中的所有记录,而领域模型的一个对象代表表中的一行记录;

一般情况下,我们可以基于第二点来严格区分你的设计是表模块的,还是领域模型的。如:如果我们有许多订单,则领域模型的每一个订单都有一个对象,而表模块只有一个对象来处理所有订单(注意,这里的类,都是指业务逻辑层的类,而不是实体类。表模块的类的对象和常规的领域模型的对象很类似,但是关键区别是:它没有标识符来标出它所代表的实体对象)。举例来说,如果要查询某个订单,表模块会像这样进行编码:

anOrderModule.GetOrder(string orderId);

因为表模块只有一个对象来处理所有订单,所以表模块可以是一个实例,也可以是一个只包含静态方法的静态类。

表模块 的代码和 事务脚本类似:

class TableModel
{
    protected DataTable table;
   
    protected TableModel(DataSet ds, string tableName)
    {
        table = ds.Tables[tableName];
    }
}

class Contract : TableModel
{
    public Contract(DataSet ds) : base (ds, "Contracts")
    {
    }
   
    public DataRow this[long id]
    {
        get
        {
            string filter = "ID=" + id;
            return table.Select(filter)[0];
        }
    }
   
    public void CalculateRecognitions(long contactId)
    {
        DataRow contractRow = this[contactId];
        double amount = (double)contractRow["amount"];
        RevenueRecognition rr = new RevenueRecognition(table.DataSet);
        Product prod = new Product(table.DataSet);
        long prodId = GetProductId(contactId);
       
        if(prod.GetProductType(prodId) == "W")
        {
            rr.Insert(contactId, amount, (DateTime)GetWhenSigned(contactId));
        }else if(prod.GetProductType(prodId) == "S")    // 电子表格类
        {
            // the sql "INSERT INTO REVENUECONGNITIONS (CONTRACT,AMOUNT,RECOGNIZEDON) VALUES (?,?,?)"
            DateTime dateSigned = (DateTime)GetWhenSigned(contactId);
            rr.Insert(contactId, amount / 3, dateSigned);
            rr.Insert(contactId, amount / 3, dateSigned.AddDays(60));
            rr.Insert(contactId, amount / 3, dateSigned.AddDays(90));
        }else if(prod.GetProductType(prodId) == "D")    // 数据库
        {   
            DateTime dateSigned = (DateTime)GetWhenSigned(contactId);
            rr.Insert(contactId, amount / 3, dateSigned);
            rr.Insert(contactId, amount / 3, dateSigned.AddDays(30));
            rr.Insert(contactId, amount / 3, dateSigned.AddDays(60));
        }
    }
   
    private long GetProductId(long contactId)
    {
        return (long)this[contactId]["ProductId"];
    }
   
    private DateTime GetWhenSigned(long contactId)
    {
        return (DateTime)this[contactId]["DateSigned"];
    }
}

class RevenueRecognition : TableModel
{
    public RevenueRecognition(DataSet ds) : base (ds, "RevenueRecognitions")
    {
    }
   
    public long Insert(long contactId, double amount, DateTime whenSigned)
    {
        DataRow newRow = table.NewRow();
        long id = GetNextId();
        newRow["Id"] = id;
        newRow["ContactId"] = contactId;
        newRow["Amount"] = amount;
        newRow["DateSigned"] = whenSigned;
        table.Rows.Add(newRow);
        return id;
    }
   
    // 得到哪天前入账了多少
    public double RecognizedRevenue(long contractNumber, DateTime asOf)
    {
        // the sql "SELECT AMOUNT FROM REVENUECONGNITIONS WHERE CONTRACT=? AND RECOGNIZEDON <=?";
        string filter = string.Format("ContactId={0} AND date <=#{1:d}", contractNumber, asOf);
        DataRow[] rows = table.Select(filter);
        double r = 0.0;
        foreach(DataRow dr in rows)
        {
            r += (double)dr["AMOUNT"];
        }
       
        return r;
    }
   
    private long GetNextId()
    {
        throw new Exception();
    }
}

class Product : TableModel
{
    public Product(DataSet ds) : base (ds, "Products")
    {
    }
   
    public DataRow this[long id]
    {
        get
        {
            string filter = "ID=" + id;
            return table.Select(filter)[0];
        }
    }
   
    public string GetProductType(long productId)
    {
        return (string)this[productId]["Type"];
    }
}

架构模式逻辑层模式之:表模块(Table Model)

时间: 2024-10-12 04:09:58

架构模式逻辑层模式之:表模块(Table Model)的相关文章

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

架构设计--逻辑层 vs 物理层

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 Layer 和Tier都是层,但是他们所表现的含义不同,Tier指的是软件系统中物理上的软件和硬件,具体指部署在某服务器上,而Layer(逻辑层)指软件系统中完成特定功能的逻辑模块,逻辑概念. Layer是逻辑上 组织代码的形式.比如逻辑分层中表现层,服务层,业务层,领域层,他们是软件功能来划分的.并不指代部署在那台具体的服务器上或者,物理位置. Tier这指代码运行部署的具体位置,是一个物

.NET应用架构设计—表模块模式与事务脚本模式的代码编写

阅读目录: 1.背景介绍 2.简单介绍表模块模式.事务脚本模式 3.正确的编写表模块模式.事务脚本模式的代码 4.总结 1.背景介绍 要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意,而不是胡子眉毛一把抓.现在有一个现象是什么呢,项目的结构从表面上看是很不错,层分的很合理,其实对业务系统来说也就那么几种层设计方法,但是现在很多项目的逻辑架构的设计不是理想,有很多概念大家并不是很了解,当然也许每个人对技术的追求不同罢了.不管你追求不追求,事实我们还是要去往正确的方向努力才对的. 很多人包

.NET应用架构设计—适当使用活动记录模式代替领域模型模式

阅读目录: 1.背景介绍 2.简单介绍领域模型模式.活动记录模式 3.活动记录模式的简单示例及要点 4.总结 1.背景介绍 对软件开发方法论有兴趣的博友应该发现最近"领域驱动设计"慢慢的被人发现被人实践起来,园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享.其实之前我也痴迷于DDD,为什么会痴迷于它并不是因为它是所谓的新技术,也不是因为各种对它的炒作,而是我觉得我找到了能解放我们进行企业业务系统开发的方法论. DDD可以很好的指导我们开发可靠的软件系统,尤其是现在的企业业务复杂多变

PHP业务逻辑层和数据访问层设计

以下还是觉得有点抽象 1.面向对象能给我们什么? 进行分析之前,我们先来复习一下面向对象.对象是要进行研究的任何事物.类是具有相同或相似性质的对象的抽象.面向对象的要素:封装.继承.多态.面向对象目的是:如何分配职责. 面向对象设计原则: 单一职责原则 (SRP) 一个类,只有一个引起它变化的原因. 开放-封闭原则 (OCP)(对外)可扩展,(对内)不可修改. 李氏替换原则 (LSP) 子类型必须能够完全替换其父类型. 依赖倒置原则 (DIP) 要依赖于抽象,不要依赖于具体. 接口隔离原则 (I

系统架构师-基础到企业应用架构-数据访问层

一.上章回顾 上篇我们简单讲述了服务层架构模式中的几种,并且讲解了服务层的作用及相关的设计规范,其实我们应该知道,在业务逻辑层中使用领域模型中使用服务层才 能发挥出最大的优势,如果说我们在业务逻辑层还是使用非领域模型的模式话,服务层的作用仅体现在解耦作用.其实在业务逻辑层采用领域模型时,我们前面说的持 久化透明的技术,其实我们可以通过服务层来做,我们在服务层中处理领域对象信息的持久化操作.当然本篇可能不会深入讨论持久化透明的具体实现,后面会单独开 篇来讲述,我们先来回顾下上篇讲解的内容:  上图

架构、框架、模式、模块、组件、插件、控件、中间件的含义和区别

架构.框架.模式.模块.组件.插件.控件.中间件的含义和区别.经常看到这些概念,但是有些含糊,花点儿功夫整理一下,结果还是有些地方理解的不透彻,先将整理的内容写下来,以供交流.左侧英文栏中有些单词被分成了两半,放到了两行中,看的时候需要注意.欢迎各路大虾.大牛.大神拍砖警醒,油锤灌顶~~~ 术语 英文解释 中文解释 软件架构 architecture:Architecture is the art of planning, designing, and constructing building

.NET应用架构设计—工作单元模式(摆脱过程式代码的重要思想,逆袭DDD)

阅读目录: 1.背景介绍 2.过程式代码的真正困境 3.工作单元模式的简单示例 4.总结 1.背景介绍 一直都在谈论面向对象开发,但是开发企业应用系统时,使用面向对象开发最大的问题就是在于,多个对象之间的互操作需要涉及数据库操作.两个业务逻辑对象彼此之间需要互相调用,如果之间的互相操作是在一个业务事务范围内的,很容易完成,但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了. 在以往,我们使用过程式的代码(事务脚本模式),将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中

项目架构开发:业务逻辑层之领域驱动失血模型

前边我们构建了个数据访问层,功能虽然简单,但是基本够用了.传送门:项目架构开发:数据访问层 这次我们构建业务逻辑层 业务逻辑是一个项目.产品的核心,也是现实世界某种工作流程在代码层面的体现. 所以,业务逻辑的合理组织构造,或更真实地反映现实业务操作,对项目的成功与否非常重要 现在业界对业务逻辑层的开发,一般会参考Martin Fowler大师提出来的针对业务层开发的四种模式 分别是面向过程的事务脚本.表模块模式,面向对象的活动记录与领域开发模式 我们要做的就是领域驱动开发模式,注意标题中的“失血