浅谈C#中的延迟加载(3)——还原“.NET研究”模型的业务规则

简介:   上一篇文章讲到把实体类中需要实现延迟加载的属性声明为virtual,然后继承实体类做一个子类,在子类里面实现该属性,配合使用委托来实现比较完美的延迟加载(原本的模型层依旧保持在最底层用于贯穿三层结构,同时又可以上海企业网站制作实现在实体类的属性里面访问到比他高层的数据访问层)。
+关注继续查看

  上一篇文章讲到把实体类中需要实现延迟加载的属性声明为virtual,然后继承实体类做一个子类,在子类里面实现该属性,配合使用委托来实现比较完美的延迟加载(原本的模型层依旧保持在最底层用于贯穿三层结构,同时又可以上海企业网站制作实现在实体类的属性里面访问到比他高层的数据访问层)。文章的最后依旧出现杯具,原因是在对模型的属性实现延迟加载之前,这个属性可能由于我们业务的需要,它并不单单是作为一个存储和读取的功能使用,而是在其get或者set的访问器中都包含这或许复杂或许简单的逻辑代码。

  举例:考虑一下这个情景,我们有一个叫做任务单的实体类,其中有两个属性,一个叫做任务名,一个叫做发布时间,现在有这样的业务规定,任务名称可以为空,但如果任务名称为空的话我们要读取发布时间生成一个任务名来代替掉这个空值(例如叫做Issue20110120191345),当然这个例子有点牵强,主要是我想不出什么很具体的实例,但是在实际开发中这种情况肯定是有的并且其中的逻辑代码有可能复杂到你难以想象。

  沿用前面两篇文章的例子,我模拟了这一现象,对文章实体类做了点修改,增加了一个名为GetCategoryRecord的字符串型属性,它的作用基本上可以从字面上看出来,叫做Category属性get访问器调用记录。于是文章类(基类)修改如下:


c#代码

namespace Model
{
// 文章实体类
public class Article
{
public int A上海徐汇企业网站设计与制作rticleID { get; set; }
public string Title { get; 上海闵行企业网站制作an style="color: #0000ff;">set; }
public string Cotnent{ get; set; }
public DateTime CreateTime { get; set; }
public int CategoryID { get; set; }
/// <summary>
/// 所属分类
/// </summary>
protected Model.ArticleCategory _category;
/// <summary>
/// 所属分类
/// </summary>
public virtual Model.ArticleCategory Category
{
get
{
GetCategoryRecord
+= "获取分类;";
return _category;
}
}
/// <summary>
/// Category属性get访问器调用记录
/// </summary>
public string GetCategoryRecord { get; set; }
}
}

  这里我们关心那两个有写注释的属性,并且出现了一个保护字段_category(这个尤其重要,起到和子类的联通作用)。可以看到现在有这样的业务规则了:Category属性被get一次就会往GetCategoryRecord属性中做点记录。于是我们在设计代码的时候立刻会想到要是继承Model.Article类的基类要是重写这个属性的话势必要保持这个业务不变,否则在实现延迟加载之后肯定会丢掉一些之前设计好的业务逻辑了。修改继承它的子类如下:


c#代码

namespace DModel
{
/// <summary>
/// 文章
/// </summary>
public class Article : Model.Article
{
/// <summary>
/// 所属分类
/// </summary>
public override Model.ArticleCategory Category
{
get
{
if (base._category == null)
{
if (CategoryLazyLoader !=上海企业网站设计与制作le="color: #000000;"> null)
{
base._category = CategoryLazyLoader(CategoryID);
}
else
{
base._category = null;
}
}
return base.Category;
}
}
/// <summary>
/// 文章分类延时加载器(委托)
/// </summary>
public Func<int, Model.ArticleCategory> CategoryLazyLoader { get; set; }
}
}

  这里可以看到DModel.Article类的Category属性中对基类的保护字段base._cateogry进行了操作,最后返回的是基类Category。粗看起来似乎有点乱,但是理清一下思路其实如下:基类的Category属性通过返回_category字段的方式返回值,也就是说数据是存在_category字段而不是属性中,但是_category字段怎么才会有值呢,那就是在子类里面通过调用委托拿来的,而这个属性在子类里面不是直接返回的,而是调用基类来返回,这样一来,调用到子类的Category属性的get访问器的时候,先对基类的_categoty字段赋值,然后调用基类的Category属性执行了一些逻辑代码,最后成功地把(已经被赋值的)基类的_categoty字段给返回去。而这一切都是在前面我们实现好的延迟加载的基础上完成的。总结成几个字就是:子类负责延时加载,基类赋值数据存储和返回!呵呵,是不是觉得很简单呢。

这里可以看到DModel.Article类的Category属性中对基类的保护字段base._cateogry进行了操作,最后返回的是基类Category。粗看起来似乎有点乱,但是理清一下思路其实如下:
基类的Category属性通过返回_category字段的方式返回值,也就是说数据是存在_category字段而不是属性中,但是_category字段怎么才会有值呢,那就是在子类
里面通过调用委托拿来的,而这个属性在子类里面不是直接返回的,而是调用基类来返回,这样一来,调用到子类的Category属性的get访问器的时候,先对_categoty字段赋值,然后调用基类的Category属性实现了一些逻辑代码,最后成功地把(已经被赋值的)_categoty字段给返回去。而这一切都是在前面我们实现好的延迟加载的基础上完成的。呵呵,是不是觉得很简单呢^^
这里可以看到DModel.Article类的Category属性中上海网站建设对基类的保护字段base._cateogry进行了操作,最后返回的是基类Category。粗看起来似乎有点乱,但是理清一下思路其实如下:
基类的Category属性通过返回_category字段的方式返回值,也就是说数据是存在_category字段而不是属性中,但是_category字段怎么才会有值呢,那就是在子类
里面通过调用委托拿来的,而这个属性在子类里面不是直接返回的,而是调用基类来返回,这样一来,调用到子类的Category属性的get访问器的时候,先对_categoty字段赋值,然后调用基类的Category属性实现了一些逻辑代码,最后成功地把(已经被赋值的)_categoty字段给返回去。而这一切都是在前面我们实现好的延迟加载的基础上完成的。呵呵,是不是觉得很简单呢^^

  其实这一篇讲的情况不是针对延迟加载这个技术来讲的,在我们的开发过程中经常会遇到这种实现了业务代码的实体类属性,拥有这种属性的模型通常被叫做充血模型,如果模型的属性都是简单的get和set的话通常叫做贫血模型(当然可能有其他叫法 哈~)。这篇文章是在没啥内容,算是对前两篇文章的一个补充吧,希望没有浪费你的时间哈^_^。

目录
相关文章
.Net Micro Framework研究—Digi开发板初探
写的比较基础全面,由于我们北航的研发团队先研究了Digi的开发板,所以直到今天Digi开发板才到我的手上,我的《Micro Framework研究》系列文章以后也会陆续推出
670 0
.Net Micro Framework研究—IO读写
试验平台:Digi MF开发板
403 0
.Net Micro Framework研究—串口操作
试验平台:Digi MF开发板,Digi提供的示例中包含了串口的示例程序
533 0
|
网络协议
.Net Micro Framework研究—TCP/IP通信
关于网络通信方面,Digi提供了两个程序,一个是TCP Server运行在Digi的开发板上,一个是TCP Client程序,运行在PC上,通过网络,上位机很容易控制Digi开发的IO信号
569 0
.Net Micro Framework研究—模拟器改造
由于Digi提供的开发板没有LCD显示屏,所以有关绘图方面的操作,只好在模拟器上进行了。
514 0
|
Windows
.Net Micro Framework研究—中文显示
微软示例程序中,仅支持两种字体(small.tinyfnt和NinaB.tinyfnt),并不支持中文。
560 0
.Net Micro Framework研究—绘图
目前在VS2005的环境里,还不支持.Net Micro Framework界面的所见即所得绘制,界面制作有三种方式,一是窗体直接绘图,二是Panel+形状对象、三是窗体+控件。第一种做法让人觉得又回到了DOS时代,回到了SCREEN 12的16色的世界里。
459 0
.Net Micro Framework研究—Shapes命名空间
在Microsoft.SPOT.Presentation.Shapes命名空间下,包含几个形状对象,主要有Ellipse、Line、Polygon、Rectangle,同样也只有Rectangle实现的最好,其他形状都不支持填充色,虽然每个对象都有Fill属性。
590 0
.Net Micro Framework研究—应用实例
在前几篇关于.Net Micro Framework的研究文章中,我对它的绘图功能实不敢恭维,不过微软的MF开发人员很聪明,对位图方面的功能实现的就比较完善,这样做起图形应用来就不至于捉襟见肘了。前段时间用.Net Compact Framework实现了一个奥运场馆查询
503 0
.Net Micro Framework研究—Tinyfnt字体研究
目前.Net Micro Framework系统仅支持Tinyfnt字体文件,官方仅提供两种字库:NinaB.tinyfnt,small.tinyfnt。
533 0
相关产品
云迁移中心
推荐文章
更多