A complete object design pattern for the database
1.1 Full-faced objects and non-complete objects
Object-oriented (OO) method This name has already been deeply rooted, and its scientific and rationality have not been doubtful. People have developed their own software crowns to "design the object-oriented method" to show that their advanced is a very good certificate. However, an advanced methodology must have the corresponding tool support to achieve, and its concept and method are not implemented, and it cannot truly master its essence and use it in practice. It is true that the SmallTalk language has been recognized as an object-oriented language, but it is very strange for developers! C can also be said to be an oo language, but you can see a variant in the C language from the name. It implements a better transition programming from process-oriented programming. But many software that claims to be made with C is still still C software! This is because there is no reason for the OO method.
Even if the developer's development environment, the development tool is to support oo (such as Delphi, VC), but the developer does not observe the problem with the software in OO, or the past process design is deeply rooted, then the developed software is still It is a processoff software that is beautiful and outer coat. No OO is used as a real-purpose method. The reason for this phenomenon is not recognizing the essence of OO, especially in some RAD development tools, easily ignoring the OO's view to observe the problem domain.
The software developed by RAD development tools is often divided into two forms: full-faced object design and non-complete object design. The architecture of a database software system is often divided into three layers: user interface layers, middleware layers, and database layers. In the user interface layer, it is often some objects that interact with the user, such as a button, menu, and dialog. In the database layer, the table is found from the problem domain. The biggest difference between the full face-to-object and non-complete objective object is the middleware layer, what is the middle part layer, the middleware layer is a problem entity in the problem domain, business rules, higher levels. The object is completely object has an intermediate layer, and there is no intermediate layer layer that is not fully opposite objects. The RAD tool is often ignored when the middleware layer is ignored.
For example: a simple billing system If you develop with the RAD tool (such as: Delphi), the user interface layer is the controls used in some systems, such as buttons, menus, etc., these control objects are used by the class in Delphi or other development tools. The library sector; the database layer is a table established at the database system (such as SQL Server, Oracle, etc.), such as customer table, product table, order table, etc.
The middleware layers in the object design are objects, business rules and other objects, as well as customers, products, and orders. Non-complete objects do not have these objects. In other words, the non-complete face-to-object object is based on the user interface layer directly access the database layer, namely: based on the control. The full-faced object is to encapsulate the database layer, the user interface layer uses the middleware layer, which is completely transparent to the database layer, which is separated from the interface, namely: object-oriented, control based on the control.
In some small systems, the non-complete object design can accelerate the development speed, but the system is flexible, the reuse is not good, the large system must adopt the development method of the fully objective object, otherwise, due to the business rules, the software is not placed. In the later stage, it will not be controlled. A successful reusable commercial software should be flexible by many object components of the middleware.
Thus, the author proposes a database that is fully object-to-object design mode.
1.2 Database A fully faced object Design Mode Do a general application to make a general application than the database program because it does not involve data inventory. But when doing a database program, consider how the class is associated with the database. Step 1: Analyze the problem domain, find out the related things in all issues, abstract objects from it.
Step 2: Find all persistent objects from abstract objects (Persisitant Object), the so-called persistence object is responsible for managing by the database management system, can be permanently reserved, and the object that will be extracted in the future will be "one" The principle of class a table is mapped to the database and establishes a table through the Database Management System.
Step 3: Define a persistent object, all persistent objects use the "Double Software Function" method to construct in the program, where a constructor parameter is all the values of the lasting object, the package data module "save" operation, The parameter of a constructor is a value that uniquely identifies the persistent object, and the "Take" operation in the package data module. Other database operations are encapsulated by a persistent object.
Step 4: All action interacting with the database layer is placed in a dedicated data module, encapsulated by the middleware layer persistent object, and the data is separated from the interface.
Step 5: Define other non-persistent objects. The specific software function is achieved by the corresponding object.
The design mode focuses on the definition of persistent objects, in addition to the double configuration, if the lasting object acquires the data number> 1, then the "persistent object set" object, "persistent object set" object consists of persistent objects, "persistent object The object set in the set "object can be screened by the corresponding SQL language in the data module. If the data in the data set is very large, the corresponding SQL language in the data module can be filtered in a fixed number, and screens. The corresponding persistent object in the object is available in the structure of the linked list. In this way, the persistent object is fully encapsulated, and the user does not even feel the existence of the database when using a lasting object, because the corresponding database operation has been packaged accordingly, the user only needs to establish The corresponding persistent object can be operated by the database.
2. The implementation of the database fully faced object design mode in the bank savings management system
2.1 Question domain objects, persistent objects and database tables
According to the idea of the above design patterns, we first identify all objects of the problem domain. Account Object 2. Savings account object 3. Regular Savings Account Object 4. Virtual Savings Account Object 5. Bank card account object
SDOS objects, bank card account objects inherit from account objects, account objects are a virtual base class, regular savings account object, and the live savings account object inherits the self-savings account, the savings account object is a virtual base class UML class level map (Figure 12)
Figure 12: Account Object UML Level Map
6. Save Object 7. Taba object 8. Trading object 9. Cost object 10. Interest rate object 11. Special operation object 12. System information object 13. Bank function object 14. Bank service object 15. Savings service objects 16. Bank card service object
Among them, savings service objects, bank card service objects inherit from bank service objects, bank service objects are a virtual base class
UML class level map (Figure 13)
Figure 13: Service Object Class Level
We then analyze the problem domain, and set the data object to be durable in the database as a persistent object. The established persistent object is: 1. Savings Account Object 2. Regular savings account object 3. Virtual Savings Account Object 4. Bank card account object 5. Save Object 6. Tabo object 7. Trading object 8. Cost object 9. Interest rate object 10. Special Operation Objects These persistent objects will be mapped to the "one type of table" to our choice of database SQL Server2000, which establishes the form and field established in the database: 2.2 Definition of problem domain objects
(1) The use of the double structure function.
It is limited to the space, this paper takes a long-lasting object-depositor object as an example, explaining the dual-constructor of the lasting object, and the definition of other persistent objects is substantially the same.
Depositor object interface definitions type TCustomer = class (TObject) private {Private declarations} protected {Protected declarations} Cus_id: string; Cus_name: string; Cus_shenfenid: string; Cus_addr: string; Cus_phone: string; procedure New_Cus_Info (c_name, c_sfid, c_addr, c_phone: string); procedure Load_Cus_info (cusid: string); public {public declarations} constructor create (c_name, c_sfid, c_addr, c_phone: string); overload; // (1) constructor Create (cusid: string); overload; / /(2)
function update_cus (): boolean; procedure Set_Cus_Id (C_Id: string); procedure Set_Cus_name (C_name: string); procedure Set_Cus_shenfenid (sfid: string); procedure Set_Cus_addr (addr: string); procedure Set_Cus_phone (phone: string); function Get_Cus_Id: String; function get_cus_name: string; function get_cus_shenfenid: string; function get_cus_addr: string; function get_cus_phone: string; published {published Declarations} END;
Depending on the database fully faced object design mode, the persistent object will constructed by two constructors (see (1), (2)), where the first constructor parameter is all the values of the lasting object, "saving" in the package data module ,
constructor TCustomer.create (c_name, c_sfid, c_addr, c_phone: string); begin New_Cus_Info (c_name, c_sfid, c_addr, c_phone); end; procedure TCustomer.New_Cus_Info (c_name, c_sfid, c_addr, c_phone: string); begin Cus_name: = C_name; file: // (1) Cus_shenfenid: = c_sfid; file: // (2) CUS_ADDR: = C_ADDR; File: // (3) CUS_PHONE: = C_PHONE; File: // (4) DModule.new_cus_info (Self) ); END; here, the SELF pointer represents a persistent object itself, since (1) - (4) has assigned a persistent object, just pressing the SELF into the data module to add a new operation of the database. The other constructor (2) parameter is a value that uniquely identifies the persistent object, and the "take" operation in the package data module. constructor TCustomer.create (cusid: string); begin Load_cus_info (cusid); end; procedure TCustomer.Load_Cus_info (cusid: string); begin Cus_id: = cusid; dmodule.load_cus_info (self); end;
The same SELF represents a data persistent object that will be acquired, only known to identify the identity value of the object (such as the number of the depositor's number of deposks), and the data module is taken on the data module (this example) The function executed in DModule.Load_cus_info (Self);) is assigned to the other attribute values for the substituted persistent object (which only the identity value of the object is assigned).
Procedure TDModule.Load_cus_info (VAR Cus: TCUSTOMER); Begin With Dcusquery Do Begin Close; SQL.CLEAR; SQL.Add ('SELECT * FROM Information Table'); // (a) Sql.add ('Where Save ID = ' ' '' '' ''); // (b) open; if not fieldbyname ('payter ID'). Isnull dam cus.set_cus_name (TRIM (FieldByName). Asstring)); // (c) Cus.set_cus_shenfenid (Trim (FieldByName) .sstring)); // (d) Cus.set_cus_addr (Trim (Trim (FieldByname) .sstring) ); // (e) Cus.set_cus_phone (Trim (FieldByname) .sstring); // (f) end; close; end; end; from database acquisition data by writing SQL language (a) , (B) implementation, assigning the data returned by SQL to the operation of the lasting object (c) - (f), so that the function is executed, the persistent object will have the value obtained from the database query.
The operation package of the database is in the data module, which facilitates the separation of the data and the interface. The data module can be used as the application service layer in the three-layer database, so that the system can easily transform into a three-layer distributed database. At the same time, the access database becomes transparent, and the user does not even know the existence of the database.
As in this example, it is only necessary to call: Var newcus: tcustom; newcus: = tcustomer.create ('Bill * Gates', '100001', 'US Microsoft', '(025) 110');
The operation of obtaining the storage of the storage of the store, such as the payment ID is 10001) is VAR NewCUS: TCUSTOMER; NewCus: = tcustomer.create ('10001');
Behind these operations have completed the corresponding operation of the database, and the data access is transparent. Moreover, the program is very readable. Then all data from this savings can read this persistent object, as we want to know the address of this depositor, we can do this: newcus.get_cus_addr;
Because the operation object is an intermediate part object, it will make the program readability very strong.
(2) Definition of "lasting object set" object
In the definition of the lasting object described above, since only a record is obtained, there is no concept of "persistent object set", and in the usual application, multiple records to the front desk processing of the background database will often be obtained at one time, although it can be Defining a record of a lasting object for access, but every new reading record must start a SQL database operation from the head, resulting in too much resource overhead, the efficiency is reduced, so if you need to read multiple records, you need Build a "lasting object set" object. Take the bank card trading object as an example
A depositor usually has multiple transactions with the bank. When we need to obtain the transaction of the bank card account, you need to obtain all the transaction object records that occur at the account, and the data set obtained is not a single lasting. Object, but a collection of persistent objects, this collection has the transaction object that occurs in this account. So here you need to define the "Persistent Object Set" object, the "lasting object set" object is also an object (Object), just its operating element is a persistent object.
In the present embodiment, the persistent object set defined set of transaction is a transaction object --Transacts, which is declared as follows: TTranode = ^ TTransactnode; TTransactnode = record TRainfo: TTransactinfo; Pnext: TTranode; end; TTRansacts = class (TObject) private {Private declarations} Pfirst: TTranode; Pend: TTranode; pos: TTranode; protected {protected declarations} Transactnum: integer; Id_ofaccount: string; id_type: integer; public {public declarations} function Get_TRas_acid: string; function Get_TRas_actype: integer; function Get_firsttrainfo: TTransactinfo ; function Get_Transactnum: integer; function Get_lasttrainfo: TTransactinfo; function Get_traninfo (tra_id: string): TTRansactinfo; function Get_nexttraninfo (): TTRansactinfo; procedure set_first; procedure TRas_add (TRa_info: TTransactinfo); constructor create (acid: string); end; " Persistent Object Set "Object - Trading Set Transacts TTRANSACTINFO in the list of linked table structure links, which constructor is initialized and the setup process of the set element is determined.
constructor TTRansacts.create (acid: string); begin TRansactnum: = 0; Id_ofaccount: = acid; Pfirst: = Nil; pEND: = Nil; dmodule.load_TRAs_info (self); end; data transaction module load_TRAs_info method set object Transacts For the parameters, the required trading objects are filtered through the SQL language, and the list of linked lists added to the trading set object is: procedure ttransacts.tras_add (TRA_INFO: TTRANSACTINFO); VAR NewNode: Ttranode; begin new (newNode); newnode.trainfo: = TRA_INFO; newNode.pnext: = nil; if pfirst = nil dam pfirst: = newNode; pOS: = pfirst; end else beg; end; pend: = newNode; pend ^ .pnext: = NIL; TransactNum: = TransactNum 1; END; only requires a trading object TransactInfo, you can add the object to the list of trading set object Transacts. Here, you must introduce the definition method of the transaction object, the transaction object uses the above-described dual-constructor to make a package of database single transaction records, where the constructor of "Take" operation is defined as follows: constructor tTransactinfo.create (of_acid: string); begin TRA_ACID: = of_acid; // of_acid trading object The corresponding account ID, the identifier value of the trading object DMODULE.LOAD_TRA_INFO (Self) end; here, DModule.Load_Tra_info (Self), and trading set objects DModule.Load_tras_info (Self) is different The former encapsulates the database "Take" operation of a single trading object, which encapsulates the database "Take" operation of the trading set object.
procedure TDModule.Load_Tra_info (var TRA: Ttransactinfo); begin with Dtinfoquery do begin TRa.SET_TRa_id (fieldbyname ( 'savings account transaction details ID') asstring.); TRa.SET_TRa_ITid (trim (fieldbyname ( 'the teller terminal number') .asstring )); Tra.set_tra_gyid (TRIM (FieldByName) .sstring); tra.set_tra_type (FieldByname) .asinteger; tra.set_tra_money (FieldbyName) .asflloat ); Tra.set_tra_time (FieldByname); tra.set_tra_result (FieldByname) .asinteger; tra.set_tra_wdname (Trim (FieldByname (') .sstring); End; end; procedure tdmodule.load_tras_info (VAR TRAS: TTRANSACTS); Begin with dtinfoquery do beg, close; sql.clear; sql.add ('select * from savings account transaction chart'); // (a) sql.add ('Where savings account ID =' '' '' tras.get_tras_acid '' '); // (b) open; if not fieldbyname (' savings account ID '). Isnull Then Begin While NOT EOF Do Begin TRAS .Tras_add (TTRANSACTINFO.CREATE (TRAS.GET_TRAS_ACID, TRAS.GET_TRAS_ Actype)); // (c) Next; end; end; close; end; end; where (a), (b) filter out all specified accounts for all specified accounts, (c) is the function of this function First, a trading object is declared (call the trading object "Take the" constructor, complete the current trading object database taking action by dmodule.load_tra_info (Self), and then add the current trading object to the trading set object through TRAS.TRAS_ADD Link list.
With a persistent object set object, you can encapsulate data inventory operations of multiple persistent objects. In this example, if you want to get all the accounts of the account "10000000000", you only need to call the operation VAR TRAS: TTRANSACTSTRAS: = TTRANSACTS. CREATE ('100000000001'),
All transactions of this account have been added to the TRAS linked list, and the chain header pointer can be obtained by tras.get_firsttrainfo, and all the operation of the linked list can be implemented. If the number of set elements of the lasting object set is huge, then the restriction statement can be added when the SQL language is filtered in the data module, and is filtered in a fixed quantity. Rayphrank (rayphrank@sina.com) Copyright,
Welcome to reprint, please indicate the author's name, email address! ! !
