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處理有什麼想法，請給些建議
在此謝謝了
