Original link: XPO a study of: Arming
The XPO for DEV is an O / R mapping framework, although it is commercial software, non-open source, but provides source code. Moreover, the DEV products have always been a boutique, it is worth studying (I am not a DEV agent).
So make a summary during the learning process.
First, a persistent class generally maps into a table type, each record of the table, is an example of a lasting class.
First, a persistent class generally maps into a table type, each record of the table, is an example of a lasting class.
The lasting class inherits from XPObject or XPBaseObject.
Public Class Customer: XPOBJECT
Creating an object creates a new record, calling the base class saved to the library.
XPObject inherits from XPBaseObject, which already contains the unique self-increment field of the OID attribute representing the table.
XpBaseObject needs to manually make some mapping work, but provide greater flexibility.
XPBaseObject implements the IXPOBJECT interface. If we go to implement this interface, you can automatically save to the database, that is, the object persistence, such as the state of the form WinForm, can be saved. Retrieve a table, actually retrieve a collection of similar objects XPCOLLECTION
Second, the interval relationship:
Support one-on-one, one-on-one, and more than three kinds of relationships.
The interval relationship of the database is reflected in the framework as a relationship between persistent objects. Generally, we are designing some similar relationships, we use the array or other collections to represent methods ilist, etc., to establish relationships between classes.
XPO uses XPCollection to represent the "Multiple Relationship" between the classes. And additional properties indicate many or more relationships.
One more:
Definition in a class:
Public class customer: XpObject {
...
[Association ("CustomeraDresses", TypeOf (Address)]]
Public XpCollection addresses {get {return getCollection ("addresses");}}
...}
Also definition in another class adresses:
[Association ("CustomeraDresses")]]]
Public Customer Customer;
At this point, the association relationship of this class does not specify the associated type because the type is already explained.
Other additional properties can be further specified in the association relationship, such as the cascade deletion relationship:
Public class customer: XpObject {
...
[Association ("CustomerORDERS", Typeof (Order), aggregated]
Public XpCollection Orders {Get {Return getCollection ("Orders");}}
...
}
More aggregated this characteristic, indicating that aggregation, that is, the cascade deletion relationship between the tables.
Method for accessing a subtoma:
enumerate
Foreach (ORDER THEORDER in thecustomer.orders)
Increase the record of the subtray:
Mycustomer.orders.Add (myorder);
Third, inquiry:
Use condition object:
For example: Freight <
10m
XpCollection Orders = New XpCollection (TypeOf (Order), New Binaryoperator ("FREIGHT", 10M, BinaryOperatorType.less);
Here, a collection class XPCOLLECTION object specified in the persistent class type is used. It doesn't mean it here can only be checked in a table. If this persistent class is related to other classes, the conditional object can contain attribute conditions for associated classes. That is, a multi-table query is implemented. The address in the following combination query is a gathering class of Customer.
Complex conditions using groupoperator. For example: Birthdate <
01/02/1960 and address.street = '' 10 '
TH avenue ''
TH avenue ''
Groupoperator criteria = new groupopertr ();
Criteria.Operands.add (New Binaryoperator ("Birthdate", New DateTime (1960, 1, 2), binaryOperatortype.less;
Criteria.Operands.add (New Binaryoperator ("Address.Street", "10 '
TH avenue "));
TH avenue "));
... New XpCollection (Typeof (Customer), Criteria
I used to make a component similar to this feature in the project. At that time, the starting point was to do a conditional object that is not related to the specific database SQL syntax, which is used to generate the SQL condition statement. Later, due to the cause of the project. I finally had an outstanding.
Fourth, inheritance and polymorphism:
To some extent, it can be said to be a problematic relationship.
XPO's persistent class supports complete inheritance and polymorphism.
For example, the management is an employee, but an employee is not necessarily managers. This we can add an identifier that managers in the employee table when designing the previous database, or builds a management table, and then makes it a relationship with the employee table by foreign key.
Such relationships can be described in the XPO: Building a employee, build a subclass of an employee class: Managers class.
PUBLIC CLASS EMPLOYEEE: XPOBJECT {
Public String lastname = ""
Public String firstname = ""
[Association ("ManageRemPloyees")]]]
Public Manager Manager = NULL;
Public Employee () {}
Public Employee (String newfirstname) {
Lastname = newlastname;
Firstname = newfirstname;
}
}
Public Class Manager: Employee
{
[Association ("ManageRemployees", TypeOf (Employee)]]
Public XpCollection Employees {
Get {return getCollection ("employees");
}
Public Manager () {}
Public Manager (String newfirstname): base (newlastname, newfirstname) {}
}
Note Use the associated properties. However, the association relationship here is merely the subsidiary employee (managers) managed by a manager. Five, session:
Manage the connection information of the database. There is a default connection: MS Access OLEDB Provider. If you use it, you don't have to initialize the instance of the session in the program. But if you want to use your own connection, two ways: First, change the connection information of the default connection, and the other is created yourself, but you must reference it when you have a persistent class. Still the first simple one. Unless the application is to consider connecting two databases
Sixth, access to the binary large object field
Use Delayed Loading:
Here, you must specify a private XPDelayedProperty type attribute, and add Attribute, a bit cumbersome in design.
Public class customer: XpObject {
...
Private xpdelayedproperty document = new xpdelayedproperty ();
[Delayed ("Document")]]]]]]]
Public Byte [] attachment {
Get {return (byte []) Document.Value;
Set {document.value = value;
}
}
7. Support for transactions:
Transactions are indispensable in the database program.
Obviously this function is provided by session.
Account Account = New Account ();
Session.defaultsession.begintransaction ();
Try {
Account.amount = amount;
Account.save ();
Session.defaultsssion.committransaction ();
}
Catch (Exception E) {
Session.defaultsssion.rollbacktransaction ();
Account.reload ();
}
Note that Reload () is used when Exception occurs.
8. Save the previous data validity check:
Class Account: XpObject {
Public Double Amount = DefaultAmount DEFAULTAMOUNT;
Protected Override Void BeforeSave () {
Base.beforeSave ();
IF (! isdeleted) {
IF (AMOUNT <0) {
Throw New Exception ("Negative Amount");
}
}
}
}
Be careful to judge the isdeleted.
Nine, concurrent operation:
Provides checking mechanisms that have changed before the object is changed. In the past, we must write code to check it yourself, now this is also available.
Ten, data paging mechanism
For large data, we generally not extracted, but batch extraction, thereby reducing memory usage and speeding up the speed. XPO provides direct support. But it didn't use XPCOLLECTION, but used another class XPCUSOR. Using the XPCollection, it also supports conditional objects, but there are more paging support.
This design idea is puzzled, why doesn't it be two?
XI, the persistence support for structures:
Still the current version just supported.
Public struct point {
[Persistent ("abscissa")]]
Public int x;
Public int y;
}
Public Class Shape: XPObject {public String Name = "";
[Persistent ("location")]]]]
Public Point position;
}
Pay attention
Attribute
The structure can last.
