Entity classes in three-tier architecture (C #)

Recently, entity classes in a three-tier architecture have caused many small issues. Let's take a look at the following and talk about your thoughts.

The entity classes referred to in this article are limited to entity classes in three layers, that is, database table ing.

 

I. Why use entity classes?

 

| EnableProgramEasy to understand and easy to maintain.

| Indicates the principle of not changing the hidden interface.

| Embodies the object-oriented thinking.

 

Example:

 

No entity class Layer 3

If the program changes, you need to add a parameter, student age

Use three layers of entity classes

Also add a parameter for student age

 

Obviously, after the entity class is used,CodeThe concept of object-oriented encapsulation is obviously concise.

Most importantly, if some changes are made in the future, you only need to modify the object class and call interfaces between methods, without any changes, which greatly reduces the number of program modifications, it caters to the idea that interfaces remain unchanged in object-oriented systems.

Even in program design, you can pre-place the attributes that may be required in the future in the object class. In this way, you do not need to change the object class in the future.

 

2. What are the disadvantages of the entity class (only personal opinions )?

 

Although the entity class has obvious advantages, a major problem is found during actual use:The code readability seems to be reduced.

What is shown in the above example is not very obvious. Here is a simple example.

Assume there is a method (No entity class is used ):

Selectbypartdate (datetime startdate, datetime enddate ){}

This method is used to query records within a certain period of time. There are two parameters: Start Time and end time.

Although no entity class is used, it makes people look very comfortable and knows what to do at a glance.

After the entity class is used (assuming that the object class name is loginlog ):

Selectbypartdate (loginlog startdate, loginlog enddate ){}

It's hard to understand what you want to do.

Of course,There are two ways to solve this problem:

| A good naming convention that allows you to learn what you mean ".

| Good documentation or code comments.

 

This raises a question:In Layer 3, do all methods use object classes to pass parameters?

The most obvious is the selectbypartdate example above, and there are methods such as deletebyid (longid. Is it really necessary to pass the object class?

The entity class is indeed easy to expand and modify, but does it not violate the design principles?

The design principle is:Avoid modifying the original code as much as possible, but solve the problem by adding code.

Methods such as selectbypartdate and deletebyid have clearly defined the purpose of querying records within a certain period of time and deleting records by ID. In other words, this is what they mean.

How can programs be expanded to involve such methods? If you have extended these methods, they have completely lost their meaning!

Deletebyid is deleted by ID. If it is extended, it is not deleted by ID! At this time, you can add a new method. Why can't you go through deletebyid?

There are few parameters and specific methodsIn my opinion, it is unnecessary to use entity classes.

This is my personal opinion. You are welcome to give me some advice!

3. Inspired by the entity class!

 

In Layer 3, we all know that the logic of the U layer should be minimized and transferred to layer B as much as possible.

However, how to transfer data in practical applications is a problem.

Take the deletion record as an example. The U layer calls layer B and layer B calls layer D. The D Layer returns a Boolean value to indicate whether the deletion is successful.

In this way, the U layer gets a Boolean value, which is true or false and carries too little information, it can only be reported to the user for success or failure (an additional judgment logic is added at the same time), but the failure is unknown.

There are many such examples in real-world applications. Sometimes, in order to give more detailed prompts to users, we will not hesitate to divide layer B into details, and then call a large number of layer B methods on the interface, A large number of judgments can be added to give users a complete prompt.

This is obviously not what we want? How can this problem be solved?

The root cause of this situation is that the Boolean return value carries too little information. Which type is more? Of course it is string type!

In layer D, you can return a Boolean value for layer B to determine whether to use it. However, the value returned to the U layer by layer B is strongly opposed to the Boolean value!

In this way, the complex logic is used in layer B, and the execution result is returned in the form of a string. In this way,The U layer does not need any judgment. Simply display the string returned by layer B!

For example (a method of layer B ):

Public String deletemail (string domainname, mail) {try {// Delete the mailbox cmdhelper = new cmdhelper (); string comment string = ""; export string = cmdhelper.exe cute ("Del" + mail. mailname + "@" + domainname + "/deleteuser"); If (Response string. tolower (). indexof ("successfully")> = 0) // deletion successful {// synchronization database imaildao maildao = creater. createmaildao (); If (maildao. deletebyid (Mail) {return "deleted successfully! The database has been synchronized! ";} Else {return" deleted successfully! But Database Synchronization failed! ";}} Else if (Response string. indexof (" the system cannot find the specified file ")> = 0) // does not exist {return" this email does not exist! ";}Else {return" unknown cause error! Contact the administrator! ";}} Catch (exception ex) {Throw ex ;}}
 

Obviously, all judgments are completed at Layer B and the results are returned to the U layer in the form of strings. This is concise and clear, and the U layer does not require any logic, just show it!

This looks good, but the string is still quite uncomfortable. Since it is object-oriented, why not return an object class?

We can define an object class named layerparameter. Add a string type resultstring attribute to this object class, and then return the string value.EncapsulationCome in. This entity class is used as the return value from layer B to the U layer.

This is perfect!

Experienced users may have encountered the problem of refreshing the interface, that is, the U layer needs to refresh the interface data according to the actual situation, especially in the B/S structure. With the entity class as the return value, you are not afraid of anything! Isn't it refreshing? Add a Boolean refresh attribute to the layerparameter object class. After calling layer B on the u layer, show the resultstring attribute of the returned value (layerparameter class instance) and tell the user the execution information, then, judge the refresh attribute and decide whether to refresh the interface data (the logic at the U layer is not impossible at all !), At this time, the return value from layer B to the U layer is still layerparameter, and the interface does not need to be changed.

The above is just my personal thoughts. Hope you can give me some advice!

 

Finally, I declare that:

All things should be based on project practices, and experience should be the king; otherwise, all discussions will be a breeze!