AccEAP架构介绍(1)---实体的设计
2006-03-05 16:58
411 查看
刚刚看到阿木的 与DotNet数据对象结合的自定义数据对象设计 (一) ,讨论数据对象的设计思想,我就AccEAP中本人的实体设计思路参与讨论。
几个开源中, 阿木也提到 IBatisNet、NHibernate是 使用自定义数据类,而且他认为”这样就有点偏离DotNet的味道了,而在需要的时候再通过一些方法去转换得到DotNet数据对象,就显得麻烦而且复杂得多“, 呵呵,那阿木可以看看 EasyObject,它是微软推荐数据集强类想化的做法,不过是在DataTable上做的。
但我一直觉得利用DotNET数据对象不是很爽,尤其在分布式架构下。当初进行Remoting 技术测试的时候,我们做了几个试验,其中之一就是对一张10000条记录的表,分别用自定义类数组传输和用数据集(DataSet)传输,传输时间和流量的对比结果另人吃惊: (我只记得结果是差了一个数量级的,但现在在家里写作,测试数据在公司,我明天一早会来更新这里,把测试结果给出来)
现在分布式系统的瓶颈更多在于对象序列化和网络开销,即使是一个客户端,机器性能对处理自定义对象于数据集的转化应该不在话下, 于是认定AccEAP架构中数据对象的包装要用自定义类。然后也是 “在需要的时候再通过一些方法去转换得到DotNet数据对象”做法了,但只要做的恰当,似乎不会 ““显得麻烦而且复杂得多”。
OK。观点既出。
我更喜欢把这里的数据对象叫做实体,似乎好像还是应该有些概念上的区别哦,先不管了。下面详细讨论一下AccEAP的实体体系结构,分 实体定义,实体容器,实体持久化,实体界面绑定,实体缓存几个方面讨论吧。
一: 实体定义
实体肯定要有一些统一的东西,比如要具备 比较 和 深度克隆的能力,要能标志出实体的基本状态(标准,更改,删除)等等,所以,基本实体类还是需要的,于是有了下面的基本的实体类(其他实体提供的能力暂时不表)
[Serializable]
public abstract class EntityBase : IComparable, IDeepCopy
[Serializable()]
public partial class Entity_AccEAP_LOG:EntityBase
{
public Entity_AccEAP_LOG()
{
// TODO: 在此处添加构造函数逻辑
}
private int _LOGID=new int();
private DateTime _LOGTIME=System.DateTime.Now;
private string _MEMO="";
private int _LOGTYPE=new int();
private int _SESSION_ID=new int();
/**//// <summary>
///
/// </summary>
public int LOGID
{
get
{
return _LOGID;
}
set
{
if (State != EntityState.Add)
State = EntityState.Amend;
_LOGID = value;
}
//剩下的属性省略
}
没什么特别的东西,需要说明的也就是 在类的定义的时候用了 partial 关键字,对了,这是个局部类,很喜欢DotNET的这个功能,一个类可以在多个地方定义。为什么用这个: 我们刚从提到了,所有的数据实体的编码都是 自动生成的,但凡事都要考虑有其特殊性,有的实体可能仅仅这样不太够用,就可以在别处去补充这个实体的定义,注意是在别处,这样和自动生成的代码分离了,当然对维护大有裨益。类似的做法,我基本在所有的由代码生成的类中都运用了,后面讲到数据库元数据封装时就能体会这种好处。
好了,实体定义基本结束,没有给它额外的能力,仅仅是自身的状态标志和 数据的封装。到现在基本还没让各位朋友看出有什么特别的地方,还要耐心。
实体是要贯穿数据持久化,业务处理,界面现实的,和这些功能处理的搭配方式决定了系统的开发方式。首要的是要有一个容器,来进行实体对象的基本管理工作,这是个重要的东西。
待续。。。
几个开源中, 阿木也提到 IBatisNet、NHibernate是 使用自定义数据类,而且他认为”这样就有点偏离DotNet的味道了,而在需要的时候再通过一些方法去转换得到DotNet数据对象,就显得麻烦而且复杂得多“, 呵呵,那阿木可以看看 EasyObject,它是微软推荐数据集强类想化的做法,不过是在DataTable上做的。
但我一直觉得利用DotNET数据对象不是很爽,尤其在分布式架构下。当初进行Remoting 技术测试的时候,我们做了几个试验,其中之一就是对一张10000条记录的表,分别用自定义类数组传输和用数据集(DataSet)传输,传输时间和流量的对比结果另人吃惊: (我只记得结果是差了一个数量级的,但现在在家里写作,测试数据在公司,我明天一早会来更新这里,把测试结果给出来)
现在分布式系统的瓶颈更多在于对象序列化和网络开销,即使是一个客户端,机器性能对处理自定义对象于数据集的转化应该不在话下, 于是认定AccEAP架构中数据对象的包装要用自定义类。然后也是 “在需要的时候再通过一些方法去转换得到DotNet数据对象”做法了,但只要做的恰当,似乎不会 ““显得麻烦而且复杂得多”。
OK。观点既出。
我更喜欢把这里的数据对象叫做实体,似乎好像还是应该有些概念上的区别哦,先不管了。下面详细讨论一下AccEAP的实体体系结构,分 实体定义,实体容器,实体持久化,实体界面绑定,实体缓存几个方面讨论吧。
一: 实体定义
实体肯定要有一些统一的东西,比如要具备 比较 和 深度克隆的能力,要能标志出实体的基本状态(标准,更改,删除)等等,所以,基本实体类还是需要的,于是有了下面的基本的实体类(其他实体提供的能力暂时不表)
[Serializable]
public abstract class EntityBase : IComparable, IDeepCopy
[Serializable()]
public partial class Entity_AccEAP_LOG:EntityBase
{
public Entity_AccEAP_LOG()
{
// TODO: 在此处添加构造函数逻辑
}
private int _LOGID=new int();
private DateTime _LOGTIME=System.DateTime.Now;
private string _MEMO="";
private int _LOGTYPE=new int();
private int _SESSION_ID=new int();
/**//// <summary>
///
/// </summary>
public int LOGID
{
get
{
return _LOGID;
}
set
{
if (State != EntityState.Add)
State = EntityState.Amend;
_LOGID = value;
}
//剩下的属性省略
}
没什么特别的东西,需要说明的也就是 在类的定义的时候用了 partial 关键字,对了,这是个局部类,很喜欢DotNET的这个功能,一个类可以在多个地方定义。为什么用这个: 我们刚从提到了,所有的数据实体的编码都是 自动生成的,但凡事都要考虑有其特殊性,有的实体可能仅仅这样不太够用,就可以在别处去补充这个实体的定义,注意是在别处,这样和自动生成的代码分离了,当然对维护大有裨益。类似的做法,我基本在所有的由代码生成的类中都运用了,后面讲到数据库元数据封装时就能体会这种好处。
好了,实体定义基本结束,没有给它额外的能力,仅仅是自身的状态标志和 数据的封装。到现在基本还没让各位朋友看出有什么特别的地方,还要耐心。
实体是要贯穿数据持久化,业务处理,界面现实的,和这些功能处理的搭配方式决定了系统的开发方式。首要的是要有一个容器,来进行实体对象的基本管理工作,这是个重要的东西。
待续。。。
相关文章推荐
- Kafka设计解析(一)- Kafka背景及架构介绍
- 介绍Web基础架构设计原则的经典论文《架构风格与基于网络的软件架构设计》导读
- PhoneGap架构介绍及NodeJS插件系统设计(一)
- 软件的架构与设计模式之模式的种类介绍
- 软件的架构与设计模式之模式的种类介绍
- 软件的架构与设计模式之模式的种类介绍
- 软件的架构与设计模式之模式的种类介绍
- 架构设计:生产者/消费者模式 第1页:“生产者/消费者模式”介绍
- 常用软件架构设计模式介绍
- 详细介绍软件架构设计的三个维度
- Kafka设计解析(一)- Kafka背景及架构介绍
- Kafka设计解析(一) Kafka背景及架构介绍
- DotNET应用架构设计指南(第一章:介绍(1-1))上传
- DotNET应用架构设计指南(第一章:介绍(3-3))上传
- [FreeMarker 2.3.20] Part I 关于模版设计的介绍 ~模板~架构总览、指令
- ProGuard介绍——《App研发录—架构设计,Crash分析和竞品技术分析》
- 详细介绍软件架构设计的三个维度
- 说说底层架构之实体类的设计
- MySQL架构设计相关的方式方法和软件介绍
- Kafka设计解析(一)- Kafka背景及架构介绍