关于领域模型
这是从一篇博客园知识库转来的，发现里面的一些介绍确实自己经历过，但却没将思想提升到领域模型上。
正文如下：
园子里这么多讨论OO的﹐我也来凑一下热闹吧。
面向对象开发一个最重要的思想就是对真实世界进行模拟。
然而﹐在大量的使用面向对象语言开发的系统中﹐您却很难看到这种模拟﹐而依然是些以数据库为中心的增删改查动作﹐很少能看到”真实的世界”的身影。
出现这种情况﹐很大程度上都是受数据库为中心的影响。
以数据库为中心开发系统﹐有一套成熟的理论﹐也经历住了多年的考验﹐是到今天为止﹐大部分信息系统开发时的不二选择。
以一个图书管理系统为例﹐有这样的一些功能﹕新书上架﹐借阅﹐归还。
按照数据库方法﹐我们会设计出这样的三个关系﹕
书籍(BookID,ISBN﹐书名﹐作者﹐出版社﹐内容简介)
借书证(CardID﹐姓名﹐电话﹐身份证号﹐地址)
借阅(BookID,CardID,借阅时间,归还时间,)
然后在数据库中建表
接下来提供书籍新增﹐删除﹐修改﹐查询﹐借书证增删改查﹐图书借阅﹐归还的人机界面
再围绕数据库编写增删改查对象和方法。大家争论的Book.Save和BookManager.Save方法也是在此吧。其实只要不重复代码﹐使用起来方便﹐高效﹐统一﹐无论将Save方法放在哪﹐都是有其道理的。
对于大部分信息系统﹐以数据库为中心是十分合适的﹐这种方法也是非常高效且成熟。
然而﹐您还是可以尝试另外一种方法
我们想象这样的场景﹕
有一个 [图书馆]
[图书馆]里有很多[书架](可以理解为﹕书籍分类目录)
[书架]上有很多[书籍]
一个读者进入系统﹐系统帮助他浏览[图书馆]的[书架],然后在其中一个[书架]中找到了他想借阅的[书籍]﹐接下来﹐它将[借书证]交给管理员﹐要求借阅该[书籍]﹐管理员办理借阅手续﹐产生一笔[借阅记录]﹐完成借書過程
这个场景可以由下面这个对象完成
Class 图书馆帮助者
{
Public List<书架> 所有书架
{
Return 图书馆.Instance.所有书架
}
Public void 选择书架(书架)
{
记录当前书架
}
Public void 选择图书(图书)
{
记录所选图书
}
Public void 借阅(借书证)
{
If(借书证.借出记录!=null)
Throw Exception “该书已借出”;
New 借阅记录();
借阅记录.Book = 当前图书
借阅记录.Card = 借书证
借阅记录.时间 = Now
当前图书.借出记录 = 借阅记录
借书证的借阅记录.Add(借阅记录)
}
}
这就是借书的用例实现﹐而这些对象则是系统领域模型中的对象。
没有数据库﹐没有UI﹐只有业务以及逻辑。
当您开发人机界面时﹐您可以选择windows﹐也可以选择web﹐它使用这个类 (显示书架﹐选择一个书籍﹐显示书架中的书籍﹐选择一本书﹐借阅按钮)完成了借阅功能
自始至终﹐我们的设计中均未出现数据库
我们的系统做为一个真实世界的模型﹐已经足够.上架时﹐只要new 书籍﹐加入书架就可以﹐办理借书证﹐也只需要new 借书证,同样﹐归还书籍时﹐只要将借出记录与书籍的关联取消即可﹐一切良好。
然而这种理想的环境是不存在的﹐这样我们才有了对象持久化的概念﹐数据库作为一个稳定﹐高效的持久方案﹐就是不错的选择(我以前也试过将所有对象以二进制文件形式间隔备份到硬盘上的方法完成持久)。
至于系统中的对象与数据库的表格如何转换﹐ORM就开始派上用场了。
然而请记住一条﹐在使用数据库存对象时﹐请千万不要和领域模型耦合在一起了(不要在借阅方法中﹐来一句Book.Insert代码﹐我们的领域对象只是互相之间有关系﹐而和数据库是没关系的﹐我们的数据库保存的是当前系统中的对象及其状态)﹐设计模式呀﹐AOP呀﹐这时候是他们大显身手的时候了
(顺便说一句﹕一直以来﹐我认为以数据库为中心而又采用ORM的系统设计方案可以说非常憋屈的﹐好好得实现您的增删改查﹐下SQL﹐连数据库不就行了﹐硬是插一脚O/R Mapping﹐让十分强大的SQL,变成笨手笨脚的对象方法﹐不难受才怪。)
其实,微软在Net框架中提供的以数据库为中心的类别和工具都已十分强大了﹐像ADO.Net,DataSet﹐类型化的DataAdapter自动生成﹐以及前端的GridView控件都适合于开发信息系统﹐大部分简单的系统我都会直接使用﹐但是﹐当C#为你提供的如此完美的一个面向对象语言﹐您又怎么能不尝试一下真正的面向对象开发呢?
