架构设计解惑资源-CSDN文库

52 浏览量 2021-02-27 03:35:45 上传评论收藏 218KB PDF 举报

资源推荐

资源详情

资源评论

架构设计解惑架构设计解惑

前言:之前的文章,很多朋友发来了反馈,从反馈中也看出了一些问题,一个最明显的问题就是:当我提到DAL的实现的时候,一些朋

友就问:DAL中采用了Repository模式吗? 初一看起来,可能认为这个问题没有什么,其实仔细的想想就会发现,确实在问题的背后

隐藏的了另外的一个问题.

本篇的议题如下:

1.问题的阐述问题的阐述

2.设计方法设计方法

3. 总结总结

1.问题的阐述问题的阐述

在项目中,我们一般都是分层,大家最熟悉的就是UI,BLL,DAL层,或者在加上一个Services服务层.一般的项目就这样设计了.由于

越来越多的公司,社区倡导领域驱动设计(DDD),于是,又有了项目的分层的方式,DDD设计中的一些概念也引入了: Presentation,

Service, Domain, Repository. 而且一般来说,有下面的对应关系:

Presentation UI

Domain BLL

Repository DAL

但是在开发的时候,一会儿在项目中建立一个Domain的类库,一会儿又在项目建立DAL,最后的情况就是:UI, Domain, DAL等等.

其实这倒是没有什么,说到底只是一个名称的问题,但是在只后面隐藏的问题就是:对DDD的不了解,很多的时候只是注重了”形”,

而没有领会到”神”.

在项目中不是建立了名称为Presentation, Domain, Repository的类库,这个项目就是DDD开发了,不是这样的.本来在分层的时候

采用UI,BLL,DAL,自己是很熟悉的,但是这样一搅和, 最后反而把概念搞复杂了.

而且,在项目中,是采用原来朴实的那种三层,还是采用DDD开发,是要经过思考的,不是那DDD的方法来套.也就是说,不要为了

DDD而DDD.就像当初我们学习设计模式一样,没有必要在写代码的过程中为了设计模式而设计模式.

2.设计方法设计方法

到底是采用DDD还是那种朴实的三层,主要取决与业务层的设计和系统的复杂度.

如果系统确实很复杂,业务逻辑相当的复杂,那么建议采用DDD,因为DDD的引入就是用解决复杂性的.因为采用DDD的方法来设

计业务逻辑层,那么业务逻辑层就只是关注业务逻辑的处理,至于怎么存储和获取数据,丝毫不关心,所以基于这个原因,在DDD中

就引入了Repository的概念,Repository就是来辅助业务逻辑层处理数据的.

虽然我一直在提”朴实的三层”,其实DDD和它之间没有什么很明显的划分了,这里我之所以特意的把他们划分出来,主要就是因为

我们在项目开发中一般是三层(或者N层),这里提出主要是为便于后面讲述一些问题.

下面就开始讲述一些业务逻辑层设计方法,相信大家看完之后,很多的疑惑就迎刃而解了.

业务层的设计方法有三种:Transaction Script, Active Record和Domain Model.

看过Flower的<<企业架构模式>>一书的朋友应该对上面的三个词语很熟悉,在书中,这些概念讲的确实很精炼,可能因为精炼,所

以理解起来就不是很容易.

在本篇文章中,就涉及到了这些知识,只有把这些点讲清楚了,之前的问题就能解决.

如果熟悉这些概念的朋友,也不妨看看,大家可以交流!

首先来看看Transaction Script(之所以没有翻译为中文，因为翻译后的中文意思很容易让人产生误导)

其实Transaction Script就是过程化的设计方式，最直观表现就是一个个的方法，每个方法做一个业务的流程。我们来看下面

一个例子。例子的背景就是在电子商务网站中订单的处理流程。

代码

public class OrderManager

{

public void PlaceOrder(OrderDTO order)

{

// Validate order based on business rules

// Check for stock availablity on items ordered

// Add the order to the database

// Set the order id on the OrderDTO object

}

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余5页未读，立即下载

内容反馈

weixin_38589150

粉丝: 6
资源: 919

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip