博客园_光影传说

EES 思宇框架升级 RTM 2.0

2011-09-21T13:09:00Z

又很久没有逛园子了

忙忙碌碌的又过了一年，原计划的框架升级计划，现在是一再推迟，一个人的力量太薄弱了

这次升级后的框架已经经过了2个项目的检验，本次主要对下列几点进行了升级：
1、增加了Smart客户端兼容，Smart客户端可以用类似Winform的代码进行编码，并可以通过代码工具生成。
2、完善了服务器端的容器，增加了环境变量，可以把容器的变量传递给程序。
3、优化完善了ORM映射，提供了ORA的映射支持，由于本人用SQL比较多，故ORA的映射支持一直没有时间增加，这次项目里要用到ORA，所以才增加进来，并统一的ORM的映射接口。
4、加强了用户代码的灵活性，程序员可以方便的通过写SQL语句的方式，编写逻辑，可以方便的获取数据库连接，并自动加入当前存在的事务环境。
5、优化的事务处理方式，特别是对连接的自动管理，打开、关闭、建立。
6、增加了客户语句的输入、传输，统一了Smart与标准程序的应用接口，从Smart终端可以与WINFORM、WEBFORM同一接口、同一配置。

Demo见附件

欢迎大家试用……

本文链接

NHibernate OR EES ，不能比较的比较

2010-09-01T03:07:00Z

或许EES 与 NH 根本就没有可比性，一个是业界久负盛名，一个是发育不良的幼儿

从老赵的BLOG里面和其他的地方了解到了一些NHibernate的处理方式，也没有深入去学习，当然，不是不想去学习，只是时间不允许去深入学习，首先要填饱肚子嘛。

关于EES的ORM，代码组织上面已经介绍过了，处理过程和很多细节方面没有作介绍，结合老赵的点评，把自己的EES ORM 部分介绍大致的介绍一下。

EES的ORM，数据模型采用的也是贫血型的领域。

典型代码
public class Order
{
   string custCode;
   public virtual string CustCode
   {
     get{retrun custCode;} set{custCode=value;}

}
    Customer customer;
    public virtual Customer Customer
    {
      get{retrun customer;}
      set{customer=value;}
    }
    
    DataCollection<OrderDTL> itemCollection;
    public virtual DataCollection<OrderDTL> ItemCollection
    {
       get{retun itemCollection;}
       set{itemCollction=value;}
    }
}

1、对于延迟加载的处理：老赵关于延迟的原文

延迟加载所用的机制与赵介绍的类似，不过，用的不是Func<>类似的处理方式，而是直接用IL写的。根据配置文件和一些条件动态生成代理类，如果需要延迟加载的，则生成延迟加载相关逻辑。如果延迟加载的，则代理类的示意代码如下：

public class DOrder : Order
{
    bool __custCode;
    public override string TagNames
    {
        get
        {
            if(!__custCode)
            {
                __custCode=true;
                base.TagNames = "……加载部分逻辑";
            }
            return base.TagNames;
        }
        set
        {
            __custCode=true;
            base.TagNames = value;
        }
    }
}

D，代表是动态类，每个动态类都是在原来类的前面加上D

在生成延迟加载逻辑的同时，根据配置文件，还生成了校验逻辑，以后面的Interceptor的处理里面，再作介绍。

2、对virtual的处理：老赵的关于Virtual处理的原文

对于virtual的处理，与NH，有稍微的不同：在EES里面（老赵可以不用抱怨了，哈哈），与数据库映射的类，其实不仅仅是与数据库映射类，用还是不用virtual，是需要考虑的。

默认状态下工具生成的代码，public 的属性都是 有virtual 的。对于同步加载的字段和不需要校验的属性，可以去掉 virtual;反过来，如果是需要校验的，则必须加上。并且在使用的时候，需要注意使用属性，而不是字段，这一点，给编码过程中引入了一个出BUG的机率。

在数据类方面，virtual 除了上面常用的这两点，还有一个重要的一点：自动维护双向关系，如果不加virtual，则系统无法自动维护双向关系，也无法实现双向绑定和级联触发。

3、对集合的处理：老赵的关于自定义集合

关于自定义集合，真的很遗憾，EES 不支持自定义集合，特别是在数据加载的时候。

对于双向关系维护，框架是提供了。都在后台处理，从编码上看，通常不需要单独处理，与老赵的处理方式有一点点的差异。上面已经提过，必须要求在属性前添加 virtual 。

DataCollection<OrderDTL> itemCollection;
    public virtual DataCollection<OrderDTL> ItemCollection
    {
       get{retun itemCollection;}
       set{itemCollction=value;}
    }

对于映射类和其他普通数据类，框架要求尽可能的从 EESObject 继承，对于集合类，尽可能的用 DataCollection 这个类。

这两个类都实现了同一个接口：ICascade

public interface ICascade
    {
        object Parent { get; set; }
    }

通过此接口实现数据的回溯。一个对象的父类，要么是一个集合要么是一个对象，有且只有一个父级。

在使用的时候可以通过强制转换来应用。在访问的时候，会在get里面会给Parent赋值。在生成动态类的时候，会根据public 和 virtual 以及 ICacscade 进行逻辑生成。

4、对于Interceptor的处理：老赵的关于Interceptor的处理

Interceptor 在EES框架里面，处于非常非常重要位置。但是在处理机制上面，与NH的距离还是不小的。介绍一下自己的处理方式，也希望大家能给出批评和建议。

在EES里，Interceptor主要提供了前/后/包围三种方式，主要应用在属性和函数上面，对于静态函数暂时不支持。使用要求与上面提到的一样，要求必须是public 并且添加 virtual 的。

对于属性的应用主要是校验和延迟加载;对于函数的应用主要是事务/日志或其他的应用，可以自行扩展。

在EES 的BLL里面，或EES 提供的数据库相关逻辑里面，提供了一点常用的其他操作和处理过程。这一点，与框架的处理思想直接相关，每个人的想法都有所差异。

在BLService里，提供了类似于老赵的这一篇回复里处理机制，但他不是Interceptor，作用类似。

public class BLService<T> : IBLService<T>, ICloneable where T : global::EES.Common.Data.EESObject
    {
        public BLService();

        protected IContext EESContext { get; }

        [Operation(ScopeOption.Required)]
        public virtual T Add(T t);
        [Operation(ScopeOption.Required)]
        public virtual DataCollection<T> AddAll(DataCollection<T> collection);
        [Operation(ScopeOption.Required)]
        protected virtual DataCollection<T> AddAllCore(DataCollection<T> collection, object state);
        [Operation(ScopeOption.Required)]
        protected virtual T AddCore(T t, object state);
        public object Clone();
        [Operation(ScopeOption.Disabled)]
        public virtual int Count(params IClause[] clauses);
        [Operation(ScopeOption.Required)]
        public virtual T Delete(T t);
        [Operation(ScopeOption.Required)]
        public virtual DataCollection<T> DeleteAll(DataCollection<T> collection);
        [Operation(ScopeOption.Required)]
        protected virtual DataCollection<T> DeleteAllCore(DataCollection<T> collection, object state);
        [Operation(ScopeOption.Required)]
        protected virtual T DeleteCore(T t, object state);
        [Operation(ScopeOption.Required)]
        protected virtual object Execute(string commandText);
        [Operation(ScopeOption.Required)]
        protected virtual object Execute(string commandText, params KeyValuePair<string, object>[] parameters);
        [Operation(ScopeOption.Disabled)]
        public virtual DataCollection<T> Find(params IClause[] clauses);
        [Operation(ScopeOption.Disabled)]
        protected virtual DataCollection<D> FindCore<D>(params IClause[] clauses) where D : EESObject;
        [Operation(ScopeOption.Disabled)]
        protected virtual T FindId(params object[] primaryKeys);
        [Operation(ScopeOption.Disabled)]
        public virtual DataCollection<T> FindPage(int currentPage, int pageSize, params IClause[] clauses);
        [Operation(ScopeOption.Disabled)]
        protected virtual T FindPair(params KeyValuePair<string, object>[] properties);
        [Operation(ScopeOption.Disabled)]
        public object LoadProperty(EESObject obj, string propertyName);
        protected virtual void OnAdded(T t, object state);
        protected virtual void OnAdding(T t, object state);
        protected virtual void OnDeleted(T t, object state);
        protected virtual void OnDeleting(T t, object state);
        protected virtual void OnSaved(T t, object state);
        protected virtual void OnSaving(T t, object state);
        protected virtual void OnUpdated(T t, object state);
        protected virtual void OnUpdating(T t, object state);
        [Operation(ScopeOption.Required)]
        public virtual T Save(T t);
        [Operation(ScopeOption.Required)]
        public virtual DataCollection<T> SaveAll(DataCollection<T> collection);
        [Operation(ScopeOption.Required)]
        protected virtual DataCollection<T> SaveAllCore(DataCollection<T> collection, object state);
        [Operation(ScopeOption.Required)]
        protected virtual T SaveCore(T t, object state);
        [Operation(ScopeOption.Required)]
        public virtual T Update(T t);
        [Operation(ScopeOption.Required)]
        protected virtual T UpdateCore(T t, object state);
    }

没有别的，又是一大堆 virtual，我自己都有点无语了，不过这里的virtual 不是为了生成动态类，而是为了在派生类里面重写。

protected virtual void OnAdded(T t, object state);
        protected virtual void OnAdding(T t, object state);
        protected virtual void OnDeleted(T t, object state);
        protected virtual void OnDeleting(T t, object state);
        protected virtual void OnSaved(T t, object state);
        protected virtual void OnSaving(T t, object state);
        protected virtual void OnUpdated(T t, object state);
        protected virtual void OnUpdating(T t, object state);

这几个空函数，主要是为了在处理层次数据的时候使用。

对于上面的Order类，可以在保存完主订单后，再调用OrderDTLService 来保存订单的明细，也可以在订单明细OnAdding里面，进行库存的核查。

关于与NH的对比，先写到这里，以后再慢慢的完善吧

还有很多与NH不相关的，但是属性框架一部分的内容，接下来，再介绍……

本文链接

EES 框架 BLL层代码组织与介绍

2010-08-30T07:03:00Z

BLL层，我个人感觉是与通用的NH/IB OR映射差异比较大的地方，处于承上启下的位置。

承上：可以与数据库打交道，起到了DAL的作用。

启下：可以与BP层/Stub层/或客户端直接打交道，作为其服务层。

public class UserImp<T> : BLService<T>
where T : EESObject, new ()
{

[Operation(ScopeOption.Disabled)]
        public virtual T FindById(String code)
        {
            return base.FindId(code);
        }
        [Operation(ScopeOption.Disabled)]
        public virtual DataCollection<T> FindByName(string name)
        {
            Where clause = new Where();
            clause.Add("Name", name);
            return base.Find(clause);
        }

[Action("保存", "保存")]
        [Operation(ScopeOption.Required)]
        public override T Save(T t)
        {
            return base.Save(t);
        }

｝

BLService<T> 为业务层的基类，主要提供增删改查的功能。默认状态下，基类的服务是不公开的，需要在此类里面公开。

Operation为事务自定义属性，通常在此处添加，也可以在配置文件里添加。

查询，也是此OR的一个特色，对于客户端和服务端的处理雷同，但不相同，服务器端可以使用 WhereEx ，支持拼接字符串和其他等特殊处理。在处理自定义查询的时候非常方便。

Action自定义属性，为动作标注，在生成Controller的时候，会自动生成。

[EESBO("User")]
public class UserService : UserImp<User>
{

[Operation(ScopeOption.Required)]
    public virtual EESContext Login(string userId, string salt)
    {

………

}

[Operation(ScopeOption.Required)]
    [Action("密码复位")]
    public virtual User ResetPwd(User user)

{

………

}

}

UserService 为常用编码的类，UserImp主要为自动生成的类，业务逻辑通常放在UserService类里面。

EESBO自定义属性标注此类为服务类，在生成代理/服务配置的时候，会自动生成配置文件和代理类。

其他的与UserImp类似。

一直在考虑，是不是要把Linq加入进去，没有决定下来。

公开的类必须添加 virtual ，使用的时候，可以用：ProxyFactory.getProxy<UserService>() 或Factory.New<UserService>,通常在服务器端用 Factory.New<UserService>()方式，在客户端用 ProxyFactory.getProxy<UserService>() 方式调用。

示例代码：

main()

{

EES.Common.Config.Configuration.Root = “……”;

User user=Factory.New<User>();

user.Code=”123456”;

UserService srv=Factory.New<UserService>();

srv.Save(user);

}

此处没有太多的处理加载的地方，系统会自动处理配置文件的加载，基于声明式事务的处理，对于多数据源和层次操作，则会一层一层的处理。

如果需要通过http进行远程调用，服务器端的UserService不需要作任何的改变，只需要加入到IIS里面，并添加些配置文件，则可通过http实现远程RPC调用，客户端代码不需要作改变，也是更改一下，添加一个自动生成的代理类则可。具体如何修改和处理，后面会继续介绍

不知道大家对于此种ORM映射的BLL处理有什么想法，请给些建议

在此谢谢了

本文链接

OR层代码组织和映射介绍

2010-08-30T06:02:00Z

OR层也是老生常谈了，有的朋友说我是重复造车轮，只是OR这部分写的太早了，更主要是的与BLL层代码的集成，非常方便，所以呢，虽然后来NH和IB出来了我没有换，MS的Linq出来了，我依然没有换，经过这几年的应用，更坚定了自己的想法。

与原来框架的主要差异是把数据映射由编码文件改为配置文件，当初考虑是方便写代码，用了之后才发觉这样太不灵活了，一直托到现在才改

从结构上来说，与原来的框架没有太多的差异，主要是把配置由自定义属性改到了配置文件。另外加入了可配置的数据校验，在Column属性中加入了一个ReadOnly的属性，对于关联关系和关联表的处理会更方便。

其中，ReadOnly默认值为false,当改为true时，如果更新数据库，此列则会跳过。加载的时候，可以根据实际需要配置成同步加载或是延迟加载。

另外在Property属性内加入校验功能，支持大小/正则表达式/范围/时间等验证

对于配置文件，默认放在Config/Map/目录下，规则为类的全名+.Config的文件：EES.H.Data.User.Config

数据库的定义连接字符串，通过SourceKey进行设置。 <SourceKey>House</SourceKey>

数据库的连接字符串配置在Config/DataSourceConfig.Config 的文件中：

<DataSourceConfig DataSourceType="MSSqlServer" DataSourceKey="House">
<ConnectionString>server=(local);database=House;Trusted_Connection=true;</ConnectionString>
</DataSourceConfig>

在加载的时候，配置文件会自动被加载，系统不需要显式处理，这点与常见的NH和IB映射应该有一定的不同，并且系统会自动处理Session的打开和关闭，以及处理多数据源等，这些会以业务层代码里面再作介绍

实体类如下：

[EESData()]
    [Contract()]
    public class User : EESObject
    {

protected String name;

/// <summary>
/// 姓名
/// </summary>
[Member(3)]
public virtual String Name
{
    get
    {
        return name;
    }
    set
    {
        if ((name != value))
        {
            this.OnPropertyChanging("Name");
            name = value;
            this.OnPropertyChanged("Name");
        }
    }
}

}

对于实体类，大同小异，都是从EESObject继承而来

EESData标注此类为数据类，另外也是为了通过工具生成界面层的视图。

Contract标注此类可远程序列化，Member为属性的可序列化，如果没有此自定义属性，则此属性不会进行远程传输序列化。

OnPropertyChanging和OnPropertyChanged在服务器端的作用不大，主要是对于客户端的双向绑定。

从这几个属性，可以看的出来，数据映射类为标准的一般类，由于中间用到了AOP，所以如果要用到校验功能，则需要在属性前加 virtual 。

对于级联的处理处理方式，采用一级对一级负责的处理方式，就如在部队里的处理一样。

对于一对多和一对一的处理采用关系配置处理。

对于主从关系的处理，还需要手工添加Slave的自定义属性，在界面生成的时候，工具会自动生成主从关系的界面。还要在属性前增加 virtaul的属性，则系统会自动处理其层次关系，如果在客户端则会自动实现级联触发。

映射层的介绍结束了，写的不到不明白的地方，请大家批评指正

本文链接

闲话一堆，老框架退休，新框架入席

2010-08-30T04:02:00Z

很少写日志，刚刚把原来写的日志全部关闭了，原来的框架已经不再使用，正式启用新的框架了。新的框架图如下：

现在新的框架主要是把老框架不足的地方去掉了，加入了更多可配置的选项，最要的几点升级如下：

1、改老框架的BL层只能与BP通信不能与Stub通信为既可以与BP通信也可以与Stub通信。

2、升级了EESObject基类，也就是原来的E2EObject这个类。统一了服务端与客户端的数据类型，消除了SDO层，业务层的数据可以直接传输到客户端，不需要经过服务层的转换。

3、把ORM由代码文件改为配置文件，并可以通过配置文件对数据进行验证等

4、增加了AOP功能，可以对数据、函数、参数进行其他的处理等

5、升级了RPC通信，改BinaryFormatter序列化为Proto序列化（不过Proto序列化中间有点Bug，通常的应用，不受影响），远程通信效率成倍提高，对于基于http的通信方式，节约了大量的带宽。并且实现了通信信道的分离，方便其他通信信道的加入，比如：MSMQ等。

6、服务容器加入了针对单个函数的授权，增加了WF的Web发布支持

7、升级了客户端的动态代理，使程序的本地调用与远程调用的统一，只需要改变配置文件，就可以把程序由单机版改为网络版。

8、对于客户端分离了视图和操作，实现了视图和功能的复用，并对视图界面增加了可配置的校验

9、升级了级联触发和双向绑定，支持WPF的绑定。使之能做到更改视图与程序代码的分离。

10、集成了fyiReporting，增加了自定义报表向导，一般的应用可以在程序发布后设计报表。支持列表、明细和主从结构。

升级的功能会在后面陆续介绍的

下一版本的功能升级计划：

1、增加可配置数据字段

2、增加远程传输属性的可配置

3、增加WF的支持

4、增加脚本功能

敬请期待……

本文链接