[Original]. Net distributed architecture development practices

. NetDistributed architecture development practices Story Origin

 

This seriesArticleThis article mainly describes a real project development process, including: Proposing problems, solving problems, architecture design, implementation of various logic layers, and emergence of new problems andCode. This series of articles is in the form of stories, and the names of many projects listed in the articles are alsoNoI am too concerned about it. Many of them are virtual.

 

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 describes the background of the project.

NewcomerRichardAssigned to an enterprise Automation Information Management Project Team-- Automation Information Management Project (AbbreviationAim), WhenRichardWhen you enter the project team, the project has started and the project architecture has been built two weeks ago.-- SOAArchitecture, and the main technologies used are finalized: WCF, LINQ.

Note: Because the project was first adopted"New Technology"(Because it was not used beforeWCF, LINQIs called a new technology.)The project starts.

 

Half a year later, the problem began to emerge.(In fact, the problem first emerged, but we still think that the problem is not big.): At the time of design, the project architecture was designed by two other people in the project team. Basically, the entire project development did not adopt the object-oriented idea, in addition, although the architecture design is divided into: data layer, business layer, service layer, andUILayer, but the layers are tightly coupled before, it can be said that it is "pull the whole body": if the data access layer is slightly changed, the business layer will follow, and then change the layers of the beginning of the impact.

 

Everyone started to think that it was very tiring, but the project had already reached this stage and it was impossible to start over again. Every time a new requirement comes, the changes to the project can be said to be overwhelming. In addition, the elder brother who designed the architecture left the project one month later.

 

The following figure shows the architecture design of the project:

I think it looks good. The general architecture is designed in this way. The following describes some call relationships between them to see if there are any problems:

Data access layer:

 

Public   Class Employeedal
{
Public List < Employee > Getallemplyees ()
{
// ...
}
}

 

WhereEmployeeYesLINQAn object generated.

 

Business Layer:

 

Code

Public   Class Employeebl
{
Public List < Employee > Getallemplyees ()
{
Employeedal =   New Employeedal ();
Return Employeedal. getallemplyees ();
}
}

 

 

Service Layer:

 

Code

Public   Interface Iemployeeservices
{
List < Employee > Getallemplyees ();
}

Public   Class Employeeservices: iemployeeservices
{
Public List < Employee > Getallemplyees ()
{
Employeebl =   New Employeebl ();
Return Employeebl. getallemplyees ();
}
}

 

 

Then generate a proxy on the client, and thenUIThe provided method is called.

 

Now, the most obvious problem is to put the data entity at the data layer.EmployeeLayer-by-layer transmission, and finally to the clientUIIn the code, while in the Business LayerEmployeeblBasically, it does not play any role.Only inInsert,Update,AndDeleteSome fields areCheckAndValidation, SuchEmailThe format is correct. Other processesCheckIt is also the accumulation of code, IndustryServices"Weak".

 

In general, it looks like"Pull your whole body".

In addition, in the development process, the benefits of layering are basically not reflected.

 

When designing a business class, all business classes appear relatively"Weak"The reason for this is mainly based on the following idea:

We all know that in the process of "Object Oriented" design, every class is like a person. instantiating a class is like generating a person. This person can have a lot of capabilities at birth.(By nature), Such as exception handling, log tracking, caching, and general verification mechanisms. It can also be born with nothing(Or only a few basic things will be done.). After the previous business class is instantiated, a very common person is generated. Each class has to rewrite a lot of basic code. When it comes to general, it is justCopyCode. If you want to make the newly generated class very powerful and have many functions, you can let these classes inherit a base class with more powerful functions during design. Of course, inheritance is only one of the implementation methods.

 

NowRichardHas been assigned to another project team(It is also a project described in this series of articles, called the project progress management system.-Project Process Management (PPM ))And designs and develops the architecture.(Previous Architecture DesignRichardNo say). With lessons learned, the months before the development of the new project,RicahrdFirst, we started the design of the general architecture for two purposes:

1.Solve the Problems of previous projects: inflexible, not universal, and repetitive tasks every time.

2.DevelopFrameworkTo make development faster, more flexible, and more powerful.

 

In fact, after the project really started, it could not be a few months for you to design the architecture. In factAimAfter a problem occurs,RichardWe are already imagining that if we develop a common frameworkNow("General"--It doesn't mean that it is available everywhere, because the company has been developing software in a certain field. For example, the current company is good at developing some software managed by the enterprise, therefore, it is still possible to develop a domain model-based architecture and framework).RichardAlso want to saveAimFor many reasons, the idea eventually becomes an idea.

 

InAimAfter the project is released,RichardThe development of another project started.EMS (employee management system), EMSThe project is not very large.RichardOne person develops this project. This project isRichardArchitecture Design andFrameworkDesign Time, becauseEMSThe project is not very complex, and the technology and progress are under control. It can be delivered on a regular basis during normal working hours. So after work every day,RichardStart working overtimeFrameworkDesign, the longer the development time, the more technologies should be accumulated, such as general class libraries, component methods or problem solution documents. Only in this way can the next development be faster.

 

3Months later,EMSThe project is complete. AndRichardDesignedFrameworkIt also has a prototype. To be accurate, it can only be called The infrastructure is basically complete.EMSThis is not usedFrameworkBecauseFrameworkDesign and ImplementationEMSIs synchronized.

 

RichardIn my mind, I think: design a general architecture, and constantly refresh, update, generate common code in the project, and then evolveFramework. Only after you have designed your ownFrameworkIn the future."Light speed development".

 

At the beginning of this project,RichardI discussed how to implement it with several other team members, and also launched my own development results. After the discussion, we decided to adoptRichard.

 

RichardWhen designing the architecture, I also referred to a popularFramework,For exampleSpring. net, csla. net, nhib.pdf, Mainly absorbing some of their ideas, but also analyzed theseFrameworkAdvantages and disadvantages of your project. Moreover, there is no absolutely omnipotent technology. The implementation of an architecture must be weighed among many factors.ShowIs used to solve the problem. This is the value of technology.

 

This series of articles shows the entire conception, design, and implementation process. The project to be developed in this series of articles may be of little value. The value of this series of articles lies in the architectural thinking and design process, and the step-by-step evolution process.

Thank you :)

Next article:. netDistributed architecture development practice 2 Draft Design

 

Welcome to the enterprise-level project development team

 

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

Http://www.cnblogs.com/yanyangtian