您的位置:首页 > 编程语言 > ASP

Asp.Net大型项目实践(3)-业务领域对象建模

2009-12-24 19:33 639 查看
你是不是已经厌倦了和数据库表一一对应的Model或Entity?
Ok~我们现在尝试真正的用面向对象的思想去设计我们的业务实体类吧....

注:这里我并不是说和数据库表一一对应的Model这种做法有多么不好,因为毕竟表驱动设计模式经过这么多年的实践,到现在也具有很强的生命力 。并且我也用这样的设计做项目多年,可是一直存在一个疑惑,为啥在处理业务的时候大牛们所鼓吹的面向对象编程思想几乎一点都没用到呢?所以这里我们做一下新的尝试,也许由于各种具体实现技术的限制和我水平有限这种尝试可能并不彻底...

按照国际惯例,我们新建一个抽象类,作为我们系统中所有业务对象的基类,将来可以用来识别哪些类是我们自己的业务对象类

namespace Demo.HIS.FrameWork.DomainBase
{
/// <summary>
/// 系统所有业务类都要继承的基类
/// </summary>
[Serializable]
public abstract class BaseObject
{
}
}


一般在信息管理系统中,大多数的业务对象都需要持久到数据库,所以我们再新建一个抽象类作为所有可以被持久化的业务对象都要继承的基类

代码

namespace Demo.HIS.Infrastructure.Core
{
/// <summary>
/// 服务项目
/// </summary>
public class ServiceItem : InputItem
{
//ServiceItem属性1
//ServiceItem属性2
}
}


应用场景举例之User
比如在我们的项目中可能登录我们系统的用户角色可能有 医生,护士,患者,医院行政人员,这几个对象的都应该属于系统用户对象
所以我们可以建立一个User抽象类,包含基本的用户名,密码等属性,且包含一些系统用户的方法比如登录,注销,修改密码等等....
然后针对 医生,护士,患者,医院行政人员这几个对象分别建类继承User抽象类,各自的对象中包含各自的属性和方法
具体的代码我就不贴了,反正这个系列以后会讲到...

以后我们的业务对象都按照这样的思路去设计,和以前我们单调的和数据库表一一对应的实体类比较起来,这样写是不是比较OO且比较有趣一些呢?

大套的理论到处都有这里就不吹了,至少我个人觉得这样写感觉上比较有设计感一些,而且对于应对需求变更的应付能力也强了很多
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐