. Net web business application architecture

Problem(Reprinted)

Microsoft was launched. it has been four years since the NET Revolution. In terms of its core CLR and C # syntax, it is indeed much better than J2EE, even Martin Flower does not consciously use C # To illustrate the OO method. However, from the perspective of commercial applications, Microsoft lags behind J2EE too much, mainly in terms of commercial application architecture. Due to the relatively weak nature of the Old Master SUN, J2EE was unable to control the situation well. Therefore, the J2EE camp experienced pain relief in the early stages of development, but finally reached an unprecedented stage by relying on open source, the J2EE camp focuses on the principles of standards, openness, and good architecture, and is now starting from Microsoft's best usability.. I am afraid the advantage of NET will continue. In contrast. NET camp, strong commercial atmosphere, due to the strength of Microsoft, resulting in pressure on any civil organizations, Microsoft's development or insertion point is based on ease of use, from some small projects of hello world or petstore, there are indeed many advantages, as if any project can be completed in the case of a plug-in, and is that true for large projects? Microsoft usually uses mouse clicks to generate hard-code, which costs a lot from the perspective of reusability, maintenance, and scalability. The Microsoft camp is used to using APIs provided by Microsoft to complete projects. the. NET camp is characterized by closed, oligarchy, and ease of use. From the current situation of Microsoft, we can only take advantage of J2EE in CLR and C # (JRE, and JAVA syntax) or infrastructure, however, when it comes to the upper-layer OR-Mapping, presentation layer framework, and AOP architecture, Microsoft has almost no advantages, and these are the most necessary architectures for building commercial applications. in the. NET project, many of these business architectures are completed by the project team .. The competition between NET and J2EE seems to be the competition between a high-quality professional corps consisting of 60 thousand people and a civil institution consisting of millions of people, the competition between "usability-> architecture" and "architecture-> usability" routes leads to victory or defeat and is only judged by history.

I suddenly found myself far away, huh, huh! It doesn't matter. I'm excited to talk nonsense. It's time to complain about living in the. NET camp for too long. Next, let's take a closer look at the. NET commercial application architecture. First of all, I would like to explain why the business architecture should be raised and what problems I want to solve. In general, what the business architecture should solve is:Improve software quality, speed up development efficiency, and reduce maintenance costs. The following describes all aspects of commercial applications:

1. OR-MAPPING: I think this is the first problem to be solved, and it is the most important aspect to be improved in commercial applications. With OR-MAPPING, you can transfer data-centric development methods to Model-centric development methods. Without solving this problem, we will never be able to achieve the highest-level Domain Model of the three basic models mentioned in enterprise application architecture Model. If this problem is not solved, the OO of the business logic layer of the key layer in the layer-3 enterprise application cannot be executed.
   
   Problem:Business logic and persistence decoupling are required, and project requirements can be implemented across databases.
   
   Possible solutions:Nhib.pdf (available in beta) and IBatis (1.0)
2. Complex query:OR-Mapping cannot solve the problem of complex queries, and HQL in nhib.pdf cannot solve this problem well. (If the query involves sub-objects, you must send additional query statements, and the entity in OR-Mapping cannot fully accommodate the fields required for the query ).
   
   Problem:The complex query implementation required by various businesses requires the Dynamic Construction of many query statements, which cannot be well unified or well maintained.
   
   Possible solutions:IBatis (version 1.0)
3. Data Dictionary:Or meta-data, that is, the structure of the data structure.
   
   Problem:Many commercial projects require custom fields, Custom reports, and custom query lists. In addition, the Code for many query conditions and lists in commercial projects is too repetitive.
   
   Possible solutions:No, but you can refer to the implementation of meta-DATA in MSCRM.
4. MVC:
   
   Problem:Needless to say.
   
   Possible solutions:MAVERICK. NET, UIPB
5. Transaction:
   
   Problem:
   
   1. database transactions cannot implement the business transaction function. You must implement the transaction functions in the form of required, nonsupported, supported, and so on.
   
   2. Start and commit a transaction. The code for rolling back the transaction is too repetitive. It is inevitable that a bug will be introduced to implement the transaction by human constraints.
   
   Possible solutions:Enterprise Services (COM +) (but it will introduce problems that are difficult to deploy)
6. Unify data verification, reading, and loading on pages
   
   Problem:Data verification, reading, and loading on many pages are similar, but repeated writing is too cumbersome. The format, such as date and amount, is required to be unified throughout the project. Developers do the same tedious operations on each page without maintenance.
   
   Possible solutions:None
7. Logs:
   
   Problem:In every commercial application, a lot of similar log code is required, which is too cumbersome.
   
   Possible solutions:Spring. NET, Aspect #, EDRA
8. Permission Verification:
   
   Problem:In every commercial application, it is too cumbersome to write a lot of similar permission verification code.
   
   Possible solutions:Spring. NET, Aspect #, EDRA
9. Resolve concurrency conflicts:
   
   Problem:The concurrency problem in WEB development is particularly serious. Each page may be opened by multiple users at the same time, and the architecture should handle this concurrency problem.
   
   Possible solutions:Chapter 1 of enterprise application architecture model is described.