Are you persistent today?

When persistence emerged, the concept of the entity layer was gradually formed. Hibernate, JDO, and nbear in the blog Park are all famous! Some companies do not use this ORM framework. They use some automatic generation tools to generate entities (for example, codesmith) and generate the business logic corresponding to the table, as a result, it seems that our programs are all well written, and the next step is easy. We only need to expand the business! Is it so convenient? Is Maintenance really the most convenient?
Other persistence layer solutions cannot be said, but at least I think it is quite troublesome to maintain the development mechanism like hibernate, the originator of ORM! An object has to correspond to an XML file (although all of these can be automatically generated). But when you go deep into the project, can we decide everything about our business? People's thinking is always changing, and the customer's needs are even more difficult to solve! One day we will add a field to the program. Do you think you have to take several steps to change it? First, we must re-generate the XML and entity, and then we must add code to the business logic, and add an interface (such as an input box) to the view layer )! To tell the truth, adding a field requires the least modification to this ORM framework. If we say that we have modified the name of the field and modified the field type, you can think about it, oh, my God! It is hard to imagine that the program associated with this field has to be changed! If the name is changed, OK. You can replace the original name with your new name. How about changing the type? There is no way to manually change all assignment types one by one, right? Verification (JS verification, business Verification), logic layer, entity layer, xml configuration, and so on in the view layer and control layer must be activated. What is HSQ? Isn't it similar to SQL? (although HSQ abstracts the database model )? But I don't think any programmer understands SQL? Besides, HSQ is insufficient for complicated statements!
Using the ORM framework will inevitably use a lot of reflection at the cost of performance. Of course, the various ORM frameworks are trying to use various methods to reduce this (lazyload, cache), and the effect is quite remarkable. However, we have sacrificed such a large performance, and I think it is the most convenient to maintain the Orm.
I really don't know why there is an xml configuration file in a framework like hibernate? If I am a real Orm, I cannot cache these data relationships. Is it okay to Dynamically Retrieve the relationships? Isn't it more flexible for me?
Of course, Using ORM also has its own advantages. In terms of maintenance, the automatic generation method (petshop mode) is much larger than using the ORM framework for maintenance, if the architecture is changed for each data operation corresponding to a stored procedure, it will be even more confusing. The architecture is roughly described as follows:
It is mainly implemented by Bll, model, and Dal three-layer architecture. BLL stores related businesses, and model stores related database table entities and SQL statements (or stored procedure parameters) of Dal businesses ). for loose coupling, factory is added to the BLL and Dal layers to facilitate carrier changes in the Dal layer (for example, changing sqlserver to MySQL ), in the Dal layer, a setobject database Field is set to the object attribute, so that the database table can be mapped to an object.
The biggest problem in programming is high coupling. How to Reduce coupling is also a top priority in development. In the above program architecture, If I modify a field in one of the tables in the database, there will be at least three layers of program changes. According to the automatic generation method, update, insert, select, and setobject In the Dal all need to be modified. If a stored procedure exists, such as get, getall, update, and insert, all must be modified, imagine how many changes have been made here? You also need to change the model layer, which can be seen in the amount of modification. Of course, here we can use an automatic generation tool to generate and replace, but who knows how much the replacement workload is here?
In short, advocating "High Cohesion and low coupling" is an eternal topic of architecture, and convenient searching is also the final goal of the architecture.
To be continued (next step: My Development Framework)