EES 框架 BLL层代码组织与介绍
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处理有什么想法,请给些建议
在此谢谢了