[Original]. NET distributed architecture development practice 5 Framework Improvement

. NET distributed architecture development practice 5 Framework Improvement

This article was intended to write about the reconstruction of the DAL. The plan is somewhat changed. In the previous article, friends in the garden gave a lot of feedback, especially thanks to some feedback from Friends of golden ocean and Virus. During the past two days of the weekend, I made some improvements to the Framework developed in the article. Although the series of articles will give code slowly, I was very excited by some ideas in the past two days, I can't wait to share it with you. It's also a quick start for the Framework provided later in the article.

 

Links to articles:

[Original]. NET distributed architecture development practices

[Original]. NET distributed architecture development practice Draft II Design

[Original]. NET distributed architecture development practice III. In-depth thoughts on data access

[Original]. NET distributed architecture development practices 4 build a bridge between ideal and implementation (previous article)

[Original]. NET distributed architecture development practice 5 Framework Improvement

[Original]. NET business framework development practices six DAL Reconstruction

[Original]. NET business framework development practices-a preliminary idea of the seven business Layers

[Original]. NET business framework development practices-eight business layer ing selection policies

[Original]. NET business framework development practices 9 Mapping attribute principles and verification rules implementation strategies

[Original]. NET business framework development practices in the first phase of the 10 Summary, a simple introduction, the water goes by the way (previous article)

[Original]. NET business framework development practices in the first phase of the 10 Summary, a simple and easy to understand (later)

 

This article does not involve much technology, but mainly involves some ideas (the code is being implemented ).

The major improvement lies in the simplified development at the business layer.

As we all know, the core of the system is the business logic layer. The business logic Code usually requires a line of code, and different systems have to write a line of code each time, the efficiency of such development can be imagined. For this reason, it is necessary to use some tools and methods to accelerate development.

 

After two days of thinking, I think the biggest improvement is the graphical configuration of business logic. I will give an example of a plot first, and then describe this idea in detail.

 

 

As you know, a BLL class contains a large number of business rules and verification rules, and these rules often need to be written manually, especially some attributes of a business class, to verify their data type, length, format, status change tracking, whether they can be read/written, and so on, although there are already some class libraries available, such as the Validation component in the Enterprise Library, however, we still need to write code. If you drag these rules in a graphical way, or configure the C # code in a graphic way, then manually modify the customized part, in this way, the development is much simpler (you can even put the automatically generated code and the code that requires handwriting in the partial class separately. You can think about how to develop the Window program in, VS puts the automatically generated code in another partial class ). Friends who have used the Sie sie Library know the power of the graphical Configuration tool.

 

First, let's look at the first figure (Design Sketch ).

 

After a new service class is added, if the service class is Product, right-click solution manager and select configure service class. A graphical configuration form is displayed, from the sketch, we can see that:

1. Properties: the attribute added for the business class.

2. DataProvider: This configuration shows which data Provider is used by the business class: AdoDotNetProvider, LinqProvider, EntityFrameworkProvider. (These providers are the providers that will be completed in the DAL series)

3. ingtype ing between the business class and the data source body. There are two options: DataTable and DataEntity (Linq entity or EF entity. The improvement of DataTable is from Golden ocean and virus, thanks)

4. mappingTypeName: This configuration item indicates which data source attributes the service class maps to. For example, MappingType is DataEntity, in addition, select the DataEntity name MS_Product (the object generated through Linq, corresponding to the MS_Product table in the database ). Of course, the attribute fields of a service class may come from the combination of multiple DataEntity. Therefore, the MappingTypeName here is multiple.

 

 

Next let's look at the second sketch.

 

When you click Properties in the first figure, this interface is used to configure the specific attributes of the service class.

Name: the Name of the attribute.

MappingTo: Specifies which attribute of the data object to map. (The data entity already created on the first interface ).

ValidationRules: used to specify the rules used for this attribute.

 

Next let's take a look at the third sketch.

 

This sketch is similar to the second sketch. It is used only to configure verification rules for specific properties.

 

I will introduce it here. I hope you will give more comments in the future to facilitate further improvement. The final developed Framework will be provided in the form of source code.

　　　　

The copyright is owned by Xiaoyang and the blog Park. for reprinting, indicate the source to the author.

Http://www.cnblogs.com/yanyangtian