This chapter mainly includes two aspects: one is a detailed description of the Framework hierarchy (controller, business object, entity, DAO), and the other is a comparison of the differences and advantages of common three-layer structures;
Let's take a look at the solution directory in the previous instance:
Let's look at the call relationships between layers:
There are four methods to operate databases in the descriptive controller,
1) The Controller calls an object and uses the ORM in the framework to perform operations on a single table.
2) The Controller directly operates on database objects (oledb) and accesses the database by writing SQL statements.
3) The Controller calls Dao to operate the database.
4) The Controller calls the business object and the Business Object calls Dao to operate the database.
There is also the role of each layer in the program structure;
I. Dao
To create a new Dao object, you must inherit the abstractdao object in the inheritance framework. The abstractdao object encapsulates the database operation object oledb. Therefore, the DAO method directly writes SQL statements to operate the database;
public class BookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao { public DataTable GetBooks(string searchChar, int flag) { string strsql = @"SELECT * FROM dbo.Books WHERE BookName LIKE ‘%{0}%‘ AND Flag={1}"; strsql = string.Format(strsql, searchChar, flag); return oleDb.GetDataTable(strsql); } }
The above code implements operations on SQL Server databases. How can I implement operations on different databases, such as Oracle and DB2? It is easy to create the ibookdao interface first, and then implement sqlbookdao and oraclebookdao respectively. The controller only needs to call the ibookdao interface to access Dao, And the DAO of the database to be operated is in efwunity. configure the config file.
Ibookdao Interface
public interface IBookDao { System.Data.DataTable GetBooks(string searchChar, int flag); }
Sqlbookdao object
public class SqlBookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao, Books.Dao.IBookDao { public DataTable GetBooks(string searchChar, int flag) { string strsql = @"SELECT * FROM dbo.Books WHERE BookName LIKE ‘%{0}%‘ AND Flag={1}"; strsql = string.Format(strsql, searchChar, flag); return oleDb.GetDataTable(strsql); } }
Oraclebookdao object
public class OracleBookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao, Books.Dao.IBookDao { public DataTable GetBooks(string searchChar, int flag) { string strsql = @"SELECT * FROM Books WHERE BookName LIKE ‘%{0}%‘ AND Flag={1}"; strsql = string.Format(strsql, searchChar, flag); return oleDb.GetDataTable(strsql); } }
Efwunity. config configuration file
Use newdao <> Operation Method in the Controller to create the configured sqlbookdao object
Based on the above, the DaO structure of different databases is designed as follows:
Ii. entity
Entity code is generated by using tools based on the database table structure information. All entities must inherit the abstractentity object in the framework, and the ing between entities and database tables does not require an xml configuration file, instead, you can use custom tags to implement ORM ing. tableattribute tags map object class names to database tables, and columnattribute tags map object attributes to database table fields. You can also map an object to multiple tables. You can configure multiple tableattribute labels and multiple columnattribute labels on the attribute directly on the class name, but they must be distinguished by the alias parameter of the label.
3. objectmodel Business Object
The business object is not created in the book management instance, because the business is too simple, only when the business process is very complex or wide-range, you can create some business objects to solve these problems. All business objects must inherit the abstractbusines objects in the framework. Business Objects cannot directly operate on databases and must be accessed through Dao. In addition, if multiple business objects are used to solve the same problem, we generally use the factory mode for design. In the framework, we can use the efwunity. config configuration file for Business Object ing;
Iv. Controller controller, including webcontroller, wincontroller, wcfcontroller, and wcfclientcontroller
Controllers are divided into three modes. controllers are created in different modes. The role of the Controller in the program structure is to link up and down. For example, the webcontroller controller converts the data structure returned by the calling logic layer into a unified JSON string and passes it to the jqueryeasyui interface. Different interface frameworks need to expand the webcontroller in the framework. We will explain in detail the implementation of various controllers in the future;
In addition, the Controller provides the database operation object oledb, which allows the Controller to directly write SQL statements to operate the database. Why should this function be enabled, this is also a design that has to be compromised due to the actual situation encountered in the project;
Similarly, all controllers must have base class controllers in the framework. The webcontroller Based on jqueryeasyui inherits the abstractjquerycontroller object, wincontroller inherits the basecontroller object, wcfcontroller inherits the jsonwcfcontroller object, and wcfclientcontroller inherits the basewcfclientcontroller object;
Then, when the controller is exposed to the UI, the custom controller labels, webcontroller and webmethod, wincontroller menu, wcfclientcontroller wcfcontroller and wcfmethod must be added;
Through the above introduction, we should have a certain understanding of the hierarchical structure of the enterpriseframework framework. Next we will discuss the differences and advantages with the common three-layer structure?
Software layering mainly involves decoupling and reuse, and may make code maintenance and expansion more convenient. Three Layers of structure include the interface layer, logic layer and data layer. The layers in the framework of iseiseframework can also be called as three layers, but they are not the same as their responsibilities. The layers in the framework can change at any time. There are four ways to adjust the layers in different situations, therefore, the enterpriseframework framework layer is highly compatible. Which of the following situations can be summarized as follows,The first is based on the difficulty of specific functions, and the second is based on the developers' code level.;
Let's compare the program structure of the petshop project:
Petshop Project Name and description: (implementation steps: 4-3-6-5-2-1)
1. Web = Presentation Layer
2. BLL = business logic layer
3. idal = data access layer interface definition
4. Model = Business Entity
5. dalfactory = Abstract Factory of the data layer (create reflection)
6. sqlserverdal = sqlserver data access layer/oracledal = ORACLE data access layer dbutility database access component basic class
Among them, the idal in 3 corresponds to the DaO interface in the enterpriseframework framework, the model corresponds to the entities in the framework, and sqlserverdal and mongoledal correspond to Dao in different databases; while the dalfactory in different 5 does not need to be in the Framework, you only need to configure the controller in the configuration file. bll in 2 also has different responsibilities and tends to design domain models in the framework. The web presentation layer in 1 separates the Controller controller into an independent layer in the framework; therefore, the ideas of the two products are quite different. I personally think that except for program code decoupling, the javasiseframework framework is more suitable for actual business and project situations;
Next, let's talk about the anemia model and the congestion model?
Anemia Model: only get and set methods in a domain object, or a small number of crud methods are included. All business logic is not included, but placed on the business logic layer.
Congestion model: the hierarchy is similar to the above, but most of the business logic and persistence are placed in the domain object, business logic (business logic layer) it simply encapsulates some business logic and controls transactions and permissions.
I personally feel deeply touched by the use of these two models. I didn't know before that this is an anemia model. The table generates all the entities, and then calls n logical objects of the entities, such code is written more and more procedural. Basically, a system can be divided into several logical objects without the concept of objects. Later, I thought this was wrong, the entity is extended into a complete business object to implement all the business operations on the entity. At the beginning, the entity still feels awkward, first, many entities have no business operations at all, and one business operation may span multiple entities. Adding business operation methods to entities is not reasonable, because the table structure design was originally not based on object-oriented, it was later evolved into the objectmodel in the javasiseframework Framework framework, which is called the domain object model. Simple businesses adopt the first model, complex businesses must analyze Domain Models and design business objects;
Finally, I would like to share my small experiences in two projects: one is to cooperate with universities and universities to develop projects, and the other is the opinions of the bosses of small companies;
Cooperating with universities and colleges to develop a project that is not too complex. The company is responsible for collecting and analyzing requirements and designing and developing universities based on requirements. A university is headed by a graduate tutor, there is no technical framework, that is, the commonly used three-tier structure. The cooperation process will not be discussed. It is the point where I feel the pitfalls of this system when I take over the maintenance code; first, a dozen or more complex system projects have been created, making it difficult to find code files. In other words, you need to change multiple files from the interface layer to the data layer for every small change; the most unbearable thing is that code reading and debugging are quite troublesome, and each layer is called by a factory reflection method. The final conclusion is that the actual project cannot be handed over to colleges and universities for development, they can work on some research projects without considering some actual situations;
Opinions of the boss of a small company. A friend started his own business as a boss and learned something about PHP Web development. He recruited a few new graduates from the school to develop a new product. He asked me to help them build a system framework, I recommended the earliest framework for them to use. At that time, there was no oledb operation database in the Controller. I first completed the development of the core business of the system and recruited several graduates to continue to improve the system on this basis, at the beginning, I was fine when I was there. If I had any questions, I could help solve them. After I found out, they exposed the problems they were doing, A simple function cannot be implemented for a long time. The new product focuses on speed and is about to be presented to the customer immediately. So a friend is eager to find the reason, although a friend will make a PHP webpage, however, through in-depth communication with several graduates, he found that the program hierarchy is too complicated. To create a function, you must draw an interface and write the controller, business object, and Dao, even more difficult, they cannot understand the controllers, Business Objects, and Dao of the logic layer at all. Therefore, they must use them in this way and often encounter some inexplicable problems; why can't I write SQL statements directly in the controller? I just said that this release will not work, it will damage the layered structure of the entire program, and there will be problems with code maintenance and expansion in the future, but I will not be able to convince him of this, he thinks that these later versions can be optimized, and now it is necessary to come out immediately; finally, As long as oledb is enabled in the Controller to operate the database;
Three-tier structure on the network:
Data access layer: it is also known as the persistent layer. Its function is mainly to access the database. Simply put, select, insert, update, and delete operations on data tables are implemented. If you want to add an ORM element, it will include mapping between the object and the data table, and object Object persistence. In the data access layer of petshop, Orm is not used, which leads to an increase in the amount of code. It can be seen as a major failure in the entire design implementation.
Business logic layer: it is the core of the entire system and is related to the business (domain) of the system. Taking petshop as an example, the related design of the business logic layer is related to the unique logic of pet shops on the Internet, such as querying pets, placing orders, adding pets to the shopping cart, and so on. If database access is involved, the data access layer is called.
Presentation Layer: it is the UI part of the system and is responsible for user interaction with the entire system. In this layer, the ideal state should not include the business logic of the system. The logic code in the presentation layer is only related to the interface elements. In petshop, ASP. NET is used for design. Therefore, it contains many Web controls and related logic.
Benefits of layering
1. developers can only pay attention to one of the layers in the entire structure;
2. It is easy to replace the original implementation with the new implementation;
3. The dependency between layers can be reduced;
4. conducive to standardization;
5. facilitate the reuse of logic at each layer.
In summary, the hierarchical design can achieve the following goals: decentralized attention, loose coupling, logic reuse, and standard definition.
Disadvantages of layering:
1. Reduced system performance. This is self-evident. If the hierarchical structure is not used, many businesses can directly access the database to obtain the corresponding data, but now it must be done through the middle layer.
2. Cascade modifications may sometimes occur. This kind of modification is especially reflected in the top-down direction. If you need to add a function in the presentation layer, to ensure its design conforms to the hierarchical structure, you may need to add the corresponding code in the corresponding business logic layer and data access layer.
10. Hierarchical Architecture and significance of the enterpriseframework framework (relationships between controllers, Business Objects, entities, and Dao)