一起谈.NET技术,领域驱动设计案例:Tiny Library:简介

  应广大网友的要求,我最近抽空基于ASP.NET MVC + WCF + Entity Framework做了一个案例,该案例以图书馆图书管理、读者借书、还书为业务背景,以领域驱动设计为思想指导,全程采用Microsoft技术进行实践,希望能够给Microsoft技术的狂热者以及领域驱动设计的学者提供实践参考。

本案例选用的业务逻辑非常简单,所以项目取名上我选用了“Tiny Library”,在后面一章我将详细介绍这个案例的业务逻辑、模型设计与系统架构。

  下载案例

  本来打算将项目发布到codeplex上,便于大家交流,也便于代码更新与维护,但由于某些原因,我无法在自己的网络环境中连接codeplex的svn/tfs服务,于是,目前只能以压缩包的形式发布案例源代码,希望大家谅解,等以后有机会更新到codeplex上后再通知大家。

【请单击此处下载案例源代码】

 

  系统需求

  • Microsoft Visual Studio 2010
  • Microsoft Patterns & Practices 5.0(v5.0.414.0,Runtime v2.0.50727。请自行到Microsoft官方网站下载安装)
  • Microsoft ASP.NET MVC 2
  • Microsoft Entity Framework(注意:是Visual Studio 2010自带的那个版本,而不是最新发布的那个Feature Pack CTP版本)
  • Microsoft SQL Express 2008 SP1
  • Apworks Application Development Framework

  请在打开本案例解决方案之前自行安装上述软件和组件!

  说明:Apworks Application Development Framework是我自己开发的一套领域驱动(Domain Driven)的应用程序开发框架,里面提供了对Aggregate Root、Repositories、Specifications以及Transaction Context的支持,基本能够满足基于Microsoft.NET技术的中小型领域驱动项目的应用开发。目前这个框架项目正在进一步实现基于CQRS体系结构模式的框架。为了节约时间,本系列文章不会对Apworks Application Development Framework做太多介绍。本框架目前也还是under construction,所以读者朋友也千万不要将其用在自己的系统开发中,以免发生危险!有关Apworks Application Development Framework的源代码以及更多信息,请访问项目站点:http://apworks.codeplex.com。Tiny Library压缩包里包含了一个可被Tiny Library使用的Apworks版本,因此读者朋友无需自己去Apworks站点上下载并编译源代码。当然,如果您希望了解Apworks的实现方式,可以使用上面的站点查看Apworks的源代码。

 

  安装部署

  1. 建立数据库
    使用Microsoft Visual Studio 2010提供的Server Explorer功能,在Data Connections上单击鼠标右键,选择Create New SQL Server Database选项,此时出现Create New SQL Server Database对话框,在对话框的Server name中输入(local)\SQLEXPRESS,在New database name中输入TinyLibraryDB,之后单击OK按钮
  2. 创建数据库Schema
    使用Microsoft Visual Studio 2010打开TinyLibrary解决方案,在TinyLibrary.Domain项目节点下找到TinyLibrary.edmx.sql脚本文件,打开此脚本文件,在SQL Editor区域,点击鼠标右键,选择Connection | Connect菜单,此时弹出Connect to Database Engine对话框,Server选择SQLEXPRESS,然后单击OK
     
    再次在SQL Editor区域点击鼠标右键,选择Execute SQL选项,执行SQL脚本以创建数据库Schema
  3. 建立演示数据(Demo Data)
    以上述同样的方式,打开TinyLibrary.Domain项目下的TinyLibrary.DemoData.sql脚本并执行
  4. 3722端口
    Tiny Library的WCF Service采用3722端口作为其服务的固定端口,因此在使用本案例钱,确保该端口未被其它应用程序占用


运行案例

  1. 在Microsoft Visual Studio 2010的Solution Explorer上,右键单击TinyLibrary Solution然后选择Rebuild Solution以重新编译解决方案
  2. 在TinyLibrary.Services项目下,选中TinyLibraryService.svc,然后单击右键,选择View in Browser,此时会自动打开ASP.NET Development Server,端口占用3722,同时打开WCF Service的页面。此时将WCF Service的页面关闭,仅留下ASP.NET Development Server
  3. 右键单击TinyLibrary.WebApp项目,选择Set as StartUp Project选项,然后在Microsoft Visual Studio中按下Ctrl+F5或者Debug | Start Without Debugging选项以启动应用程序
  4. 应用程序启动后,可以看到主界面如下
     

 

登录账号

测试需要,Tiny Library默认提供三个用户账户:daxnet、acqy和james。用户名、密码如下:

  1. 登录名:daxnet;名称:DaxNet;密码:daxnet@live.com
  2. 登录名:acqy;名称:Sunny Chen;密码:acqy@163.com
  3. 登录名:james;名称:james;密码:james@tinylibrary.com

 

额外说明

时间有限,本案例仅仅是一个基于Microsoft.NET技术的领域驱动设计实践案例,因此,如下内容没有包含在本案例中:

  1. 基于AOP和Policy Injection的技术实践。这包括:异常处理、数据验证与系统日志
  2. 基于用户/角色验证的图书维护页面
  3. ASP.NET MVC的高级应用
  4. WCF的异常捕获与显示
  5. 单元测试
  6. 其它的一些技术细节

有兴趣的朋友可以在本案例源代码的基础上进行扩充,以实现一套完整的图书馆管理应用。

时间: 2024-09-11 03:48:44

一起谈.NET技术,领域驱动设计案例:Tiny Library:简介的相关文章

领域驱动设计案例:Tiny Library:简介

应广大网友的要求,我最近抽空基于ASP.NET MVC + WCF + Entity Framework做了一个案例,该案例以图书馆图书管理.读者借书.还书为业务背景,以领域驱动设计为思想指导,全程采用Microsoft技术进行实践,希望能够给Microsoft技术的狂热者以及领域驱动设计的学者提供实践参考. 本案例选用的业务逻辑非常简单,所以项目取名上我选用了"Tiny Library",在后面一章我将详细介绍这个案例的业务逻辑.模型设计与系统架构. 下载案例 本来打算将项目发布到c

领域驱动设计(DDD)的实践经验分享之持久化透明

前一篇文章中,我谈到了领域驱动设计中,关于ORM工具该如何使用的问题.谈了很多我心里的想法,大家也对我的观点做了一些回复,或多或少让我深深感觉到面向对象设计和领域驱动设计是两个不同层次的东西.你会面向对象并不代表你就会面向领域设计.后来,我无意中发现了一个网站,http://www.jdon.com,这个网站中所包含的知识在我看来非常深入,而且基本上都包含了现在一些最新的设计思想.我看了几篇文章后渐渐感觉到领域驱动设计并不是我想象中那么简单.其实学技术,学框架并不是太难,只要你肯花时间就一定能慢

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

Vaughn Vernon谈微服务和领域驱动设计

虽然单体应用程序也可以实现相当好地建模,但它们常常会演变成一团乱麻.究其原因是单体应用程序内的多个领域模型错综复杂地交织在一起.根据Vaughn Vernon的经验,这种情况在几周或几个月内就会出现.在今年早些时候举行的Scala Days大会上,他在演讲中表达了这样的观点. Vernon是<实现领域驱动设计>和<通过Actor模型实现响应式消息处理模式>这两本书的作者.他指出,当应该保持独立的领域模型混在了一起,互相无法区分时,就很难或者不可能和业务及领域专家一起从逻辑上推断模型

Vaughn Vernon 谈微服务和领域驱动设计

虽然单体应用程序也可以实现相当好地建模,但它们常常会演变成一团乱麻.究其原因是单体应用程序内的多个领域模型错综复杂地交织在一起.根据Vaughn Vernon的经验,这种情况在几周或几个月内就会出现.在今年早些时候举行的Scala Days大会上,他在演讲中表达了这样的观点. Vernon是<实现领域驱动设计>和<通过Actor模型实现响应式消息处理模式>这两本书的作者.他指出,当应该保持独立的领域模型混在了一起,互相无法区分时,就很难或者不可能和业务及领域专家一起从逻辑上推断模型

如何实现领域驱动设计

从Eric Evans写下经典名著Domain-Driven Design: Tackling Complexity in the Heart of Software至今,DDD刚好发展了十年的时间.它几乎成了开发复杂软件系统主要的领域设计方法,既是面向对象(组件)设计的补充,又超越了面向对象(组件)设计.DDD中提出的诸多概念如实体.值对象.聚合等,已经成为了耳熟能详的设计术语.DDD社区的发展也如火如荼,似乎并没有被层出不穷的设计思想所取代,相反,它仍在强劲地发展,吸收了许多新的概念与方法,

领域驱动设计的编码: 数据聚焦型开发的技巧

今年,Eric Evans 具有开创性的软件设计图书"Domain-Driven Design: Tackling Complexity in the Heart of Software"(领域驱动设计:软件核心复杂性应对之道) (Addison-Wesley Professional,2003 年,amzn.to/ffL1k)迎来了其出版十周年的纪念日.Evans 在本书中分享了其指导大型企业完成构建软件的过程的多年经验.他随后花了更长时间考虑 如何概括帮助这些项目获得成功的模式 -

关于DDD领域驱动设计的理论知识收集汇总

最近一直在学习领域驱动设计(DDD)的理论知识,从网上搜集了一些个人认为比较有价值的东西,贴出来和大家分享一下: 我一直觉得不要盲目相信权威,比如不能一谈起领域驱动设计,就一定认为国外的那个Eric Evans写的那本书中的一些概念就一定是正确的,认为领域驱动设计就一定是聚合,聚合根,实体,值对象等概念.我们要有自己的思想,要有自己判断真正的领域模型该是什么样子的勇气和追求. "领域驱动设计" = "问题域模型驱动领域建模" + "领域建模驱动软件实现&q

领域驱动设计系列(转)

曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们,你们是否有过这样的痛苦经历:当需要修改一个Bug的时候,面对一个类中成百上千行的代码,没有注释,千奇百怪的方法和变量名字,层层嵌套的方法调用,混乱不堪的结构,不要说准确找到Bug所在的位置,就是要清晰知道一段代码究竟是做了什么也非常困难.最终,改对了一个Bug,却多冒出N个新Bug.同样的情况,当你拿到一份新的需求,需要在现有系统中添加功能的时候,面对一行行完全过程式的代码,需要使用一个功能时,不知道是应该自己编写,还是应该寻找是否已