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

阅读目录:

  • 1.背景介绍
  • 2.简单介绍表模块模式、事务脚本模式
  • 3.正确的编写表模块模式、事务脚本模式的代码
  • 4.总结

1.背景介绍

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

很多人包括我自己在内,都是写过很多年的过程式的代码,层对我当年来说就是个摆设而已,最典型的问题就是我们总是将表模块模式和事物脚本模式一起混着使用,什么意思呢,就是说我们都会使用一些代码生成器来根据数据库中的表来生成三层架构中的业务层和数据层,有些比较好的代码生成器也可以帮你把UI层中的部分视图也生成好,确实很强大,有些场合下这是一中最合适的过程。

但是现在的系统已经不在是那样的了,其中重要的一点就是业务复杂了,如果我们还稀里糊涂的编写着代码,最后只会成为你或者团队的技术债务。

2.简单介绍表模块模式、事务脚本模式

我们简单了解一下这里所谓的“表模块模式、”事务脚本模式“到底是什么样子的模式,最关键是你也许就知道了你目前所使用的业务层架构风格是什么模式,强调一下“表模块模式”、“事物脚本模式”都是业务层的构架模式。

表模块模式:

简单讲就是你数据库中的每个表对应着业务层中的一个对象定义,如果你有一个Product表,那么你在Business Layer中就有一个Product.cs文件,当然这不是绝对的,你也可以将库中的视图也定义一个类型,如,OrderProduct.cs,也是可以的。然后每个类中的所处理的逻辑都是跟这张表相关的,你在Product.cs中的代码就不要包含Order.cs中的代码了。目前来看是有的,因为现在大部分的项目都是在写着使用过程式的代码,也就是事物脚本模式,这样难免会将其他类型中的代码写到本类中。

事物脚本模式:

事务脚本模式就是过程式的代码,只不过它的指标就是每一个代码段独立完成一个业务单元,而不是到处都是过程代码,事物脚本模式还是很强调逻辑的统一性的。

使用此模式进行写代码时,你就不要单纯的使用数据库中的表名来定义业务类了,因为你是使用事务脚本模式的,你需要站在业务角度来规划你的业务层中大概包含哪些业务概念,然后使用这个业务概念来命名你的类。比如:UserOrder,UserOrder,类似这样的定义,当然这里只是个假设而已,你不要站在数据库的脚本来设计业务层就行了,这样你就起码不会使用到很细粒度的类型,哪怕下一次迭代进行重构也是可以的。

3.正确的编写表模块模式、事务脚本模式的代码

这篇文章的重点就是本节,我们将了解一下这两种模式的代码到底该如何编写。

说代码如何编写似乎有点让人觉得不是很礼貌,其实我们大部分的代码写的都是正确的,但是如果我们将有些代码稍微的罗一下位置就会明显不一样。

我们来看一个小例子,例子很简单,有两个类型Order、Product,用来完成一般的业务逻辑处理,我们通过不同的模式来看到底如何使用。

现在的事务脚本模式的代码:

namespace Business
{
    public class Order
    {
        [Serializable]
        public class OrderField
        {
            public string OId { get; set; } 

            [NonSerialized]
            public List<Product.ProductField> Products { get; set; }
        } 

        public OrderField Field { get; set; } 

        public void AddOrder(OrderField orderField)
        {
            var sendMQOrders = new List<string>();//合格的产品ID集合 

            orderField.Products.ForEach(product =>
            {
                if (product.Price <= 20)//不满足条件
                    return; 

                sendMQOrders.Add(product.PId);//满足条件
            }); 

            MqHelper.SendOrder(orderField, sendMQOrders);//发送订单数据实体到队列中
        }
    }
}

Order业务类中有一个添加Order的方法,在该方法中是一些简单的业务逻辑处理,判断了要添加的这个商品的价格是否大于20块钱。最后使用过滤下来的商品ID作为本订单的有效产品。

这就是我们目前使用的代码风格,这里有两个问题,第一:类的命名,Order的概念太大了,没有进行细化,显然不是按照事务脚本模式来进行设计的而是按照表模块方式进行划分的,还有如果我就算你是按照事物脚本模式来设计的,我就喜欢定义大的概念难道不对吗?也可以,但是在Order的定义里面明确使用了Product类型下的子类型,也就说这里出现了两个独立的业务范围,正常的理解肯定是按照表模块模式来设计的。第二:如果是按照表模块模式来设计的,因为根据这个对象的命名很明显是此模式,但是仔细阅读一下代码发现职责还是有点不清晰,在Order.AddOrder(OrderField orderField)方法中,有Product的逻辑在里面if (product.Price <= 20),当然这里是业务逻辑比较简单的情况下的,如果是业务比较复杂的时候,就会出现大量的代码在Order类中,到最后就会发现我们已经分不清此业务架构到底是使用何种模式来设计的。

我们有两个做法,第一个做法是:将其改成事务脚本模式,让类的命名和设计泛化,也就是说不要定义那么明显的数据库中的表名字,不要清晰的区分Order和Product两个职责。第二个做法是:将其改成表模块模式,将每个类型中的业务逻辑完全清晰化,将if (product.Price <= 20)提取到Product业务类中去,然后在应用控制器中先处理此逻辑后在调用Order.AddOrder(OrderField orderField)方法进行处理,这个方法里面只做跟当前类型相关的逻辑,参考的依据就是一旦你发现你所写的代码里出现了别的类型时,此时你应该告诉自己有可能这个地方需要重构职责。

两个方法来移动此逻辑:

1:(将if (product.Price <= 20)封进Price属性中)

namespace Business
{
    public class Order
    {
        [Serializable]
        public class OrderField
        {
            public string OId { get; set; } 

            [NonSerialized]
            public List<Product.ProductField> Products { get; set; }
        } 

        public OrderField Field { get; set; } 

        public void AddOrder(OrderField orderField)
        {
            var sendMQOrders = new List<string>();//合格的产品ID集合 

            orderField.Products.ForEach(product =>
            {
                if (product.Price.IsValid()/*执行价格判断*/) return; 

                sendMQOrders.Add(product.PId);//满足条件
            }); 

            MqHelper.SendOrder(orderField, sendMQOrders);//发送订单数据实体到队列中
        }
    }
}

此方法有个问题就是商品的价格没有收到订单的控制,这看具体的业务需要了,我只是个假设。

2:完全独立的过滤无效产品的方法

namespace Business
{
    public class OrderApplicationController
    {
        public void SubmitOrder(Order.OrderField field)
        {
            field.Products = new Product().FilterProduct(field.Products);//先过滤 

            new Order().AddOrder(field);//在添加
        }
    }
}

我们先调用Product中的业务方法过滤无效的商品,然后在进行订单添加操作,这样我们就将各自的职责放到自己的位置去。

4.总结

还是那句话,这只是我学习过程中的一点小小的领悟,给大家一个参考的资料,希望对你有用,谢谢。

作者:王清培

出处:http://www.cnblogs.com/wangiqngpei557/

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

让弹幕文明一点的Python屏蔽功能小实验

突然想到一个视频里面弹幕被和谐的一满屏的*号觉得很有趣,然后就想用python来试试写写看,结果还真玩出了点效果,思路是首先你得有一个脏话存放的仓库好到时候检测...

34050
来自专栏喵了个咪的博客空间

phalapi-入门篇6(小技巧和浅谈API适用范围以及入门篇总结)

#phalapi-入门篇6(小技巧和浅谈API适用范围以及入门篇总结)# ? ##前言## 先在这里感谢phalapi框架创始人@dogstar,为我们提供了这...

37850
来自专栏IMWeb前端团队

聊聊http/2

本文作者:IMWeb 九月 原文出处:IMWeb社区 未经同意,禁止转载 随着web的发展,http/1.x 已经很难满足现在的需求,Google 因...

23770
来自专栏iOS技术

设计一个简单的 iOS 架构前言一、关于组件化二、模块化思维划分文件三、减少全局宏的使用四、去基类化设计五、MVC?MVP?MVVM?VIPER?结语

正如“100个读者就有100个哈姆雷特”一样,对于架构的理解不同的软件工程师有不同的看法。架构设计往往是一个权衡的过程,每一个架构设计者都要考虑到各个因素,比如...

19330
来自专栏程序人生

系统开发之设计模式

上周五同事分享了design patterns in networks,里面很多patterns都是做路由器防火墙这样的转发设备之所以高效的精髓所在。「程序人生...

35750
来自专栏java达人

tryLock的一个使用示例

就算是有几年工作经验的,如果没有专业的训练,也不一定能写出一手线程安全的代码,对于一般的web开发而言,多线程相关的部分都封装在web server里了,而平时...

20550
来自专栏沈唁志

你认为该怎么样学习PHP?PHP成长之路

31850
来自专栏FreeBuf

pyMagic:用python控制的Geek入门神器

原创作者:comover 大学四年快要结束了,这几年也学习了一点新的姿势。最近一直在跟国外的micropython项目,这个项目是由剑桥大学的理论物理学家(th...

46650
来自专栏逸鹏说道

一个粗心的Bug,JSON格式不规范导致AJAX错误

一、事件回放 今天工作时碰到了一个奇怪的问题,这个问题很早很早以前也碰到过,不过没想到过这么久了竟然又栽在这里。 当时正在联调一个项目,由于后端没有提供数据...

36940
来自专栏花叔的专栏

实践并解读最新的小程序码生成方式

花叔一看到这个新特性时就开始着手研究这特性怎么应用,经过一轮测试,终于有点成绩,来看看花叔的研究成果,希望对大家有用。

45160

扫码关注云+社区

领取腾讯云代金券