三层架构,够不够---DDD眼中的三层(附C#源代码实现)

软件复杂度的根本,来源于思维的复杂度。

三层架构

从DDD看三层

DDD的三层实现详细架构

看代码

业务域 (Domain)

持久层 (数据层)

测试和使用的例子

完整代码下载

 


 

得心应手武器库:

  • Fluent nHibernate

  • nUnit

  • Git (GitHub)

 本文所涉及使用的工具, 见前文: 我的.Net武器库 ------ 新.Net架构必备工具列表

三层架构

相对于目前日新月异的新概念,新名词,三层架构已经算得上元老了。虽仍有争议,但业界更多的是共识。

图1 常用三层的描述图

 

足够简单、清晰,我仍要提醒的是,注意层之间连线的箭头,非常之重要,借用UML的定义,箭头表示依赖关系。也就是说,必须先有数据层,才有业务层,然后才有表现层。这又怎么样,小问题。不,这是一个大麻烦!

从DDD看三层

我们暂时靶这个话题放一放,挑个比较新一点的东西。业务域驱动开发(DDD) 近年也是风生水起,红红火火,但它是什么,是怎么回事,似乎就不如三层架构那么妇孺皆知了。

图2 从DDD的角度看三层架构

 

以业务域为系统的核心,所有其它与业务无关的内容对这个核心来谈,都是外部服务/功能。这里,出于本文说明的需要,独立出了两个较为特别的外部功能,持久层和用户接口。

两个看上去完全不同的架构设计,哪个更对哪个更好?每一个都有大量的拥护者,大量的讨论,互相三间似乎又泾渭分明,至少我们经常看到的文章给我们如此的印象。自然,我们的思考,为什么不能融合在一起呢?其实,它们并不像看起来区别那么大。从名词上,虽然我有意把名称错开,我们也仍能看到之间的对应关系、业务层=业务域,数据层=持久层,表现层=用户接口。当然,这些细节用词的不同仍有必要的,毕竟,它们不完全是一回事。

DDD的三层实现详细架构

好了,抽象的讨论已经足够了,我们也足够糊涂了。细节为王,我们如何实现?来看看这个实际系统的简化架构图。.

图3 实际架构设计

 

可以看到,在保留了清晰的三层外,重要的是把依赖关系改变了。而所谓依赖注入(DI),只是一种实际的技术实现,完成和实现这种架构设计需求。也可以清晰的看到,图中是以Domain为核心的。 当然,这是一个简化又简化的示意图,不想一开始就把事情弄的复杂.

看代码

最后,来看看具体的代码,才有更好的体验。

业务域 (Domain)

考试类:

很简单的一个考试类,可以看到,域中的类定义几乎不受持久层(数据库)影响,除了两点:

1.属性ID是从数据表的主键而来;

2. 如果要用nHibernate的Lazy Load每个属性都必须是Virtual。

即使如此,这个类已经足够干净了。我也看到,一些系统实现,专门定义了一个基础类Entity,然后,把ID的定义放在这个类中. 我觉得很没必要, 画蛇添足。

作为示例,这个域类很简单, 但却是核心的核心。项目越往后,这一层膨胀的越厉害。后面几部分,现在看起来比较多,复杂。之后,不会有大的变化,反而显得会越来越简单。

仓储接口:

注意到:

1. 接口命名,我没有加I,这是特意的。

2. 用到了Query<>接口, 这个是对查询的一个抽象。好处是,不需要像大多数的仓储实现,要为每个类建立一个仓储接口,膨胀的很厉害。

Quer接口很简单,没有任何方法和属性,只是为了使用强类型。它的实现类会根据需要, 越来越多。 因为,查询几乎就是数据层的主要功能。

查询接口的定义:

持久层 (数据层)

考试映射类:

Fluent nHibernate对仓储接口的实现:

Fluent nHibernate的配置:

使用的SQLite文本数据库,作为示例。

测试和使用的例子

自动创建数据库:

这里,只是用测试的形式,实现功能。如果运行这个测试,将自动生成数据库。并且,可以输显示数据库生成脚本。在产品环境下,我就是用这个脚本来做数据库安装的。

操作数据(模拟UI):

同样,用测试的形式,模拟UI的数据的操作。
首先,运行Create_a_exam()插入一个考试对象。
然后,运行get_the_exam_by_id()获取刚插入的考试。
运行 delete_the_exam()删除考试。

(本文版权属于© 2012 - 2013 予沁安 | 转载请注明作者和出处WangHaoBlog.com

完全代码下载

posted @ 2012-04-16 06:40 予沁安 阅读(...) 评论(...) 编辑 收藏