The controversy over the development architecture

In the development of the standard user system, Jacty and I had a long debate on the development of architecture.

In the day-long debate, we've come to understand the difference between traditional three-tier development, ORM, and db4o.

1. In previous projects, we abstracted individual entities. According to the principle of object-oriented, these entities are given certain attributes and methods. These entities, plus some tool classes, form the business logic layer. Our bottom layer is a class similar to the SqlHelper. The top level is the page.

2. For the above improvements: in practice, we find that almost all physical layers have three basic methods: adding, deleting, changing and checking. In this way, we have established a virtual class: substance. Each entity is then inherited from substance. Substance completed the basic action: Add, Delete, change.

So that each subclass needs only its own attributes and additional methods. Greatly improved the efficiency of writing. In this way, we form a four-layer pattern.

3. In further exploration, we find that the operation of the data in both entity classes and substance has a characteristic-the operation of Tanku. So there is a substance and the bottom of an intermediate layer: singgletable, carried out on the Tanku packaging, making it more conducive to sorting, paging and so on. In this way, I oh Macheng for a "four-storey structure."

4. After referring to Microsoft's PetShop, we found that the entity as a model is a better way. This allows the action to be defined as an interface, thus adapting the factory pattern to different layers. So we think the standard user system is developed in this way.

5. In the in-depth study of PetShop, we found that PetShop is not entirely object-oriented. It's just an "object-oriented" output, not an "object-oriented" input or Output object. Because in the BLL layer of petshop, the return type is an entity defined by the model layer, and even when multiple records are returned, there is no use of the traditional dataset, and the IList generics are used. Its output is indeed object oriented. But what about his input. For example, to add an order, you can pass a orderinfo (the entity of order) into, this is object-oriented. But it's time to retrieve the IList of an order that meets certain conditions. It requires an incoming coherent condition. According to Oo, a orderinfo instance should be passed in as a sample query. Moreover, the PetShop model layer, all entity attributes are used by the value type. But according to Object-oriented thinking, where there are foreign keys, you should design an instance of another object as a property. If you have two classes now: Order and product. An order contains a product, at which point an attribute of the productinfo should be of type, not a string ProductID.

In addition, there are a lot of duplicate code petshop. such as in the Sqlserverdal layer (that is, the concrete implementation of the function of the layer, located in. " NET Pet Shop 4.0/sqlserver "), most of the code is duplicated with Oracle-related implementations.

To solve the above problems, we have launched a heated discussion. Especially for the third question, we have proposed some solutions. If so, why would Microsoft write so many duplicate code? This is simply because the operation of the data and the operation of the business logic are not separated. Business logic can be understood as "when an event, you need to get that information, and then the new type of data or non-data operations," and data manipulation refers to open the data persistence layer, data reading and writing. Microsoft's BLL layer is unable to separate logical operation and data operation, so it causes the duplication of the code. We are therefore committed to this aspect.

But after a day of discussion, we finally had to find it frustrating. If we solve this problem and let our systems seamlessly adapt to new databases or DB4O, NH, and so on, we have to implement an ORM for access and SQL Server, and we should be able to manipulate the data like we do with db4o. The difficulty is not less than developing a set of db4o, and then developing a set of standard-oriented object-oriented data query language.

At present, Db4o has made some progress in object-oriented query language, but object-oriented query language has a congenital weakness, so that db4o can not be widely used now. The ideal object-oriented search language should be based on a sample query, update and other operations. But in the query, in the end which fields to match, which do not match it. Db4o, in the search for int, the incoming sample of the INT-type property is not as a matching condition, the string is empty when the matching condition is not ... But the problem is, assuming that I'm trying to figure out what the 0 value is. Suppose I just want to find out what to do with the null value.

So, finally, we find that this series of problems is simply not our ability to solve.

But in the end, there is always a solution to be formed. We discussed the decision. An object-oriented approach to input and output. But in the BLL layer of the specific operation is the same as Microsoft's PetShop.