EES framework BLL-Layer Code Organization and introduction

On The BLL layer, I personally feel that it is quite different from the general NH/IB OR ing.

Integration: it can deal with databases and play the role of DAL.

Start: You can directly deal with the BP/Stub Layer/or client as its service layer.

Public class UserImp <T>: BLService <T>
Where T: EESObject, new ()
{
[Operation (scostmtion. Disabled)]
Public virtual T FindById (String code)
{
Return base. FindId (code );
}
[Operation (scostmtion. Disabled)]
Public virtual DataCollection <T> FindByName (string name)
{
Where clause = new Where ();
Clause. Add ("Name", name );
Return base. Find (clause );
}
　　　　　　　　
[Action ("save", "save")]
[Operation (ScopeOption. Required)]
Public override T Save (T t)
{
Return base. Save (t );
}
}

BLService <T> is the base class of the business layer and mainly provides the addition, deletion, modification, and query functions. By default, services of the base class are not made public and must be made public in this category.

Operation is a custom transaction attribute. It is usually added here or in the configuration file.

Query is also a feature of this OR. The processing on the client and server is the same, but not the same. The server can use WhereEx to support splicing strings and other special processing. It is very convenient to process custom queries.

The custom attribute of Action, which is the Action annotation. It is automatically generated when the Controller is generated.

[EESBO ("User")]
Public class UserService: UserImp <User>
{
[Operation (ScopeOption. Required)]
Public virtual EESContext Login (string userId, string salt)
{
.........
}
[Operation (ScopeOption. Required)]
[Action ("Password Reset")]
Public virtual User ResetPwd (User user)
{
.........
}
}

UserService is a common encoding class, And UserImp is mainly an automatically generated class. business logic is usually placed in the UserService class.

The EESBO custom attribute indicates that this class is a service class. When the proxy/service configuration is generated, the configuration file and proxy class are automatically generated.

Others are similar to UserImp.

I have been thinking about whether to add Linq to it, but it is not decided.

The public class must be added to the virtual. You can use ProxyFactory when using it. getProxy <UserService> () or Factory. new <UserService>, usually Factory. new <UserService> () method, use ProxyFactory on the client. getProxy <UserService> () method call.

Sample Code:

Main ()
{
EES. Common. Config. Configuration. Root = "…";
User user = Factory. New <User> ();
User. Code = "123456 ";
　　　　　　　　
UserService srv = Factory. New <UserService> ();
Srv. Save (user );
}

There is not much processing load here. The system will automatically process the loading of configuration files. For declarative transactions, multi-data source and hierarchical operations will be processed layer by layer.

If you need to make a remote call through http, the server's UserService does not need to be changed. You only need to add it to IIS and add some configuration files. Then, you can implement remote RPC through http, the client code does not need to be changed, but is also changed. You can add an automatically generated proxy class.