{"id":100279,"date":"2017-04-29T22:09:05","date_gmt":"2017-04-29T14:09:05","guid":{"rendered":"http:\/\/www.ilzhi.cn\/?p=100279"},"modified":"2017-04-29T22:22:59","modified_gmt":"2017-04-29T14:22:59","slug":"xpo-%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%ef%bc%88xpo-best-practices%ef%bc%89","status":"publish","type":"post","link":"http:\/\/www.ilezhi.cn\/?p=100279","title":{"rendered":"XPO \u6700\u4f73\u5b9e\u8df5\uff08XPO Best Practices\uff09"},"content":{"rendered":"
\u6765\u6e90\uff1ahttps:\/\/www.devexpress.com\/Support\/Center\/Question\/Details\/A2944<\/a><\/pre>\n
1. Always define a constructor with a Session parameter in your persistent objects.
\n<\/strong>This will help you prepare for point 4 (see below) and will also allow you to avoid the exception explained in the\u00a0<\/span>A751<\/span>\u00a0article.
\n<\/span><\/span><\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
public class OrderDetail : XPObject {\r\n   public OrderDetail(Session session) : base(session) { \r\n   }\r\n   \/\/ ...\r\n}<\/pre>\n
[VB.NET]<\/strong><\/p>\n
Public Class OrderDetail\r\n   Inherits XPObject\r\n   Public Sub New(ByVal session As Session)\r\n       MyBase.New(session)\r\n   End Sub\r\n   ' ...\r\nEnd Class<\/pre>\n
<\/p>\n
2. Use the SetPropertyValue method in persistent property setters.<\/strong><\/p>\n
Here is the recommended code for a persistent property:
\n<\/span><\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
string fProductName;\r\npublic string ProductName {\r\n   get { return fProductName; }\r\n   set { SetPropertyValue(\"ProductName\", ref fProductName, value); }\r\n}<\/pre>\n
[VB.NET]<\/strong><\/p>\n
Private fProductName As String\r\nPublic Property ProductName() As String\r\n   Get\r\n       Return fProductName\r\n   End Get\r\n   Set(ByVal value As String)\r\n       SetPropertyValue(\"ProductName\", fProductName, Value)\r\n   End Set\r\nEnd Property<\/pre>\n
Q.<\/strong>\u00a0Why must I define a property rather than just a field (public string ProductName;<\/em>)? Why should I use a SetPropertyValue rather than simply setting a value to a class field?<\/p>\n
A.<\/strong>\u00a0XPO expects an Object Changed notification, when a persistent property’s value is changed. For instance, this notification is used to include the modified object into the UnitOfWork’s Objects To Save collection. The\u00a0SetPropertyValue<\/strong>\u00a0method sends this notification by calling the object’s\u00a0OnChanged<\/strong>\u00a0method, while a simple field assignment does not.\u00a0<\/span>
\nQ.<\/strong>\u00a0Why not to use a GetPropertyValue in a property’s getter?\u00a0<\/span>
\nA.<\/strong>\u00a0Code like\u00a0return fProductName;<\/em>\u00a0is faster than a call to the GetPropertyValue method. When it comes to reading persistent properties, the access time is critical, because it’s a frequent operation. Please refer to the\u00a0<\/span><\/span>XPO Simplified property syntax<\/span>\u00a0article to learn more.<\/span>
\nQ.\u00a0<\/strong>Should I use the GetPropertyValue\/SetPropertyValue methods for delayed properties?\u00a0<\/span>
\nA.<\/strong>\u00a0You must use the GetDelayedPropertyValue\/SetDelayedPropertyValue or GetPropertyValue\/SetPropertyValue methods to correctly handle delayed loading.<\/span>
\nQ.\u00a0<\/strong>The GetDelayedPropertyValue\/SetDelayedPropertyValue methods does not provide overloaded method to specify the property holder. How to implement the extended variant of the delayed property, and include different delayed properties in one group?\u00a0<\/span>
\nA.\u00a0<\/strong>In this scenario, the following construction can be used:
\n<\/span><\/span><\/span><\/p>\n
[C#]<\/strong><\/p>\n
private XPDelayedProperty fPicture = new XPDelayedProperty();\r\n[Delayed(\"fPicture\", \"GroupAttributes\")]\r\npublic byte[] Picture {\r\n    get { return (byte[])fPicture.Value; }\r\n    set { fPicture.Value = value; }\r\n}<\/pre>\n
[VB.NET]<\/strong><\/p>\n
Private fPicture As New XPDelayedProperty()\r\n<Delayed(\"fPicture\", \"GroupAttributes\")> _\r\nPublic Property Picture() As Byte()\r\n    Get\r\n        Return CType(fPicture.Value, Byte())\r\n    End Get\r\n    Set(ByVal value As Byte())\r\n        fPicture.Value = value\r\n    End Set\r\nEnd Property<\/pre>\n
 <\/p>\n
\t\t<\/code><\/p>\n
3. Explicitly set the XpoDefault.DataLayer property in the entry point of your application.<\/strong>
\n<\/span><\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
[<\/span>STAThread<\/span>]<\/span>\r\nstatic<\/span> void<\/span> Main<\/span>(<\/span>)<\/span>\r\n{<\/span>\r\n   string<\/span> conn<\/span> =<\/span> AccessConnectionProvider<\/span>.<\/span>GetConnectionString<\/span>(<\/span>@\"ApplicationData.mdb\"<\/span>)<\/span>;<\/span>\r\n   XpoDefault<\/span>.<\/span>DataLayer<\/span> =<\/span> XpoDefault<\/span>.<\/span>GetDataLayer<\/span>(<\/span>conn<\/span>,<\/span> AutoCreateOption<\/span>.<\/span>DatabaseAndSchema<\/span>)<\/span>;<\/span>\r\n.<\/span>.<\/span>.<\/span>      \r\n}<\/span><\/code><\/pre>\n
 <\/p>\n
[VB.NET]
\n<\/strong><\/span><\/p>\n
<STAThread()> _\r\nShared Sub Main()\r\n   Dim conn As String = AccessConnectionProvider.GetConnectionString(\"ApplicationData.mdb\")\r\n   XpoDefault.DataLayer = XpoDefault.GetDataLayer(conn, AutoCreateOption.DatabaseAndSchema)\r\n...\r\nEnd Sub<\/pre>\n
Without this code, each new Session or UnitOfWork will create a new data layer for its exclusive use. The data layer creates a new connection to your database. This is not advisable for at least for two reasons:<\/p>\n
1. Establishing a connection to a database is a long lasting operation. It may cause performance issues.
\n2. Your application may exceed of the maximum DB connection limit.
\nWhen the XpoDefault.DataLayer is set, all Session and UnitOfWork objects, which were created with their default constructors (without a DataLayer parameter), share a given XpoDefault.DataLayer object. This will also help you get prepare for Best Practices #4 (see below). Please note that setting an XpoDefault.DataLayer doesn’t prevent you from creating a new connection to your database when you need one (e.g. for emulating a multi-user application for testing purposes): You can create a new SimpleDataLayer instance, pass it to the Session’s constructor as a parameter and use this Session as your needs dictate.
\n<\/span><\/p>\n
4. Use a new Session \/ UnitOfWork instance to fully control loading, modifying and saving data.<\/strong>\u00a0XPO Session caches objects. By creating a new Session\/UnitOfWork instance for data processing, you acquire better control over reloading data and saving changes. We advise that you utilize a separate UnitOfWork instance in all visual modules (Forms and UserControls) of your application.\u00a0See an example here:\u00a0<\/span>How to view persistent objects in the XtraGrid and edit them in a separate window<\/span>.
\n<\/span><\/span><\/p>\n
5. Avoid the use of a default session.<\/strong>\u00a0The XPO default Session is accessible via the\u00a0XpoDefault.Session<\/strong>\u00a0or\u00a0Session.Default<\/strong>\u00a0static property. The default session is used internally when objects or XPCollection instances are created without a Session parameter. This may result in a\u00a0SessionMixingException<\/strong>and\/or make you write cumbersome code for reloading data (see\u00a0<\/span>How XPO reloads objects and collections<\/span>). To avoid these problems, please don’t use the default session:
\n1. Set XpoDefault.Session to null (Nothing) in the entry point of your application:
\n<\/span><\/span><\/p>\n
[C#]<\/strong><\/span><\/p>\n
XpoDefault<\/span>.<\/span>Session<\/span> =<\/span> null<\/span>;<\/span><\/code><\/pre>\n
[VB.NET]<\/strong><\/span><\/p>\n
XpoDefault.Session = Nothing<\/span><\/code><\/pre>\n
2. Remove default constructors from your persistent classes.
\n<\/span><\/p>\n
6. Use a UnitOfWork rather than Session.<\/strong>\u00a0When a Session is used, and its transaction isn’t explicitly started, a persistent object is immediately persisted in the data store upon the\u00a0<\/span>Save<\/span>\u00a0method call. Unlike Session, UnitOfWork doesn’t persist changes until its CommitChanges method is called. Thus, the UnitOfWork gives you more control over\u00a0what<\/em>\u00a0and\u00a0when<\/em>\u00a0to save. See also:\u00a0<\/span>Unit of Work<\/span>.
\n<\/span><\/span><\/p>\n
7. Create a separate application for database maintenance and schema updates.<\/strong>\u00a0For security reasons, you may wish to deny access to system tables and disable modifications to the database schema for the database account used in your end-user application. Please use the AutoCreateOption.SchemaAlreadyExists option when creating a DataLayer in your XPO application. In this case, you can grant fewer privileges to the database user account used in your application. To create a database schema, please write a separate application, which calls the UpdateSchema and CreateObjectTypeRecords methods:
\n<\/span><\/p>\n
[C#]<\/strong><\/span><\/p>\n
string conn = ...;\r\nIDataLayer dl = XpoDefault.GetDataLayer(conn, DevExpress.Xpo.DB.AutoCreateOption.DatabaseAndSchema);\r\nusing(Session session = new Session(dl)) {\r\n   System.Reflection.Assembly[] assemblies = new System.Reflection.Assembly[] {\r\n       typeof(AnyPersistentObjectFromAssemblyA).Assembly,\r\n       typeof(AnyPersistentObjectFromAssemblyB).Assembly\r\n   };\r\n   session.UpdateSchema(assemblies);\r\n   session.CreateObjectTypeRecords(assemblies);\r\n}<\/pre>\n
[VB.NET]
\n<\/strong><\/span><\/p>\n
Dim conn As String = ...\r\nDim dl As IDataLayer = XpoDefault.GetDataLayer(conn, DevExpress.Xpo.DB.AutoCreateOption.DatabaseAndSchema)\r\nUsing session As Session = New Session(dl)\r\n   Dim assemblies As System.Reflection.Assembly() = New System.Reflection.Assembly() _\r\n       { GetType(AnyPersistentObjectFromAssemblyA).Assembly, GetType(AnyPersistentObjectFromAssemblyB).Assembly }\r\n   session.UpdateSchema(assemblies)\r\n   session.CreateObjectTypeRecords(assemblies)\r\nEnd Using<\/pre>\n
8. Creating criteria<\/strong><\/p>\n
Refer to the\u00a0<\/span>Creating Criteria<\/span>\u00a0and all related topics to master this fundamental element in the DevExpress components and XAF\/XPO frameworks world. Take special note that the same criteria can be represented by many ways. For example, if I want to filter only objects, which have a value equal to or greater than 20 in their “UnitPrice” field I can use the following criteria:
\n<\/span><\/span><\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
CriteriaOperator criteria = new BinaryOperator(\"UnitPrice\", 20, BinaryOperatorType.GreaterOrEqual);\r\nCriteriaOperator criteria = new OperandProperty(\"UnitPrice\") >= new OperandValue(20);\r\nCriteriaOperator criteria = CriteriaOperator.Parse(\"UnitPrice >= ?\", 20);\r\nCriteriaOperator criteria = CriteriaOperator.Parse(\"UnitPrice >= 20\");\r\nCriteriaOperator criteria = CriteriaOperator.Parse(string.Format(\"UnitPrice >= {0}\", 20));<\/pre>\n
The first three approaches are the best here because they lead to less errors. From them the first two are even strongly-typed which is yet better. To learn more about this, check out the\u00a0<\/span>Simplified Criteria Syntax<\/span>\u00a0help topic and\u00a0<\/span>this video<\/span>. The third one utilizing positional parameters (they are specified via the ? character) is also safe enough. The last two approaches are also correct but not so safe. We don’t recommend using them widely. Normally, you can use them only if you know exactly what you are doing and you are an expert in the\u00a0<\/span>criteria language syntax<\/span>. This is because, for example, you should be attentive about the correct syntax when specifying values of various types as literals and so lead to errors. See the Literals section in the previous help topic for more information.<\/span><\/p>\n
Bonus: Persistent objects etiquette for enterprise applications<\/strong><\/span>
\nHere,\u00a0<\/span>Etiquette<\/span>\u00a0means a simple set of rules, which are not enforced, but if followed, will simplify your life significantly:
\n\u2022 Never use Session.DefaultSession for actual persistent objects.
\n\u2022 Never use an XPBaseObject if not really required. Use XPCustomObject or XPObject as base classes.
\n\u2022 Never produce side effects on a persistent property assignment. At the very least, don’t change or check directly or indirectly other persistent properties between OnLoading and OnLoad (while IsLoading == true).
\n\u2022 If you need to enforce your business rules in the properties setters or getters, always check the\u00a0<\/span>IsLoading<\/span>\u00a0value:
\n<\/span><\/span><\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
private string name;\r\npublic string Name {\r\n    get { return name; }\r\n    set {\r\n        bool changed = SetPropertyValue(\"Name\", ref name, value);\r\n        if (!IsLoading && changed) {\r\n            ... YourBusinessRule...\r\n        }\r\n    }\r\n}<\/pre>\n
[VB.NET]<\/strong><\/p>\n
Private _name As String\r\nPublic Property Name() As String\r\n    Get\r\n        Return _name\r\n    End Get\r\n    Set(ByVal value As String)\r\n        Dim changed As Boolean = SetPropertyValue(\"Name\", _name, value)\r\n        If (Not IsLoading) AndAlso changed Then\r\n            ...YourBusinessRule...\r\n        End If\r\n    End Set\r\nEnd Property<\/pre>\n
or use the following technique:<\/p>\n
[C#]
\n<\/strong><\/span><\/p>\n
[Persistent(\"Name\")]\r\nprivate string PersistentName {\r\n   get { return name; }\r\n   set { SetPropertyValue(\"PersistentName\", ref name, value); }\r\n}\r\n[PersistentAlias(\"PersistentName\")]\r\npublic virtual string Name {\r\n   get { return PersistentName; }\r\n   set {\r\n       DoMyBusinessTricksBeforePropertyAssignement();\r\n       PersistentName = value;\r\n       DoMyBusinessTricksAfterPropertyAssignement();\r\n   }\r\n}<\/pre>\n
[VB.NET]<\/strong><\/p>\n
<Persistent(\"Name\")> _\r\nPrivate Property PersistentName() As String\r\n   Get\r\n       Return name\r\n   End Get\r\n   Set(ByVal value As String)\r\n       SetPropertyValue(\"PersistentName\", name, value)\r\n   End Set\r\nEnd Property\r\n<PersistentAlias(\"PersistentName\")> _\r\nPublic Overridable Property Name() As String\r\n   Get\r\n       Return PersistentName\r\n   End Get\r\n   Set(ByVal value As String)\r\n       DoMyBusinessTricksBeforePropertyAssignement()\r\n       PersistentName = value\r\n       DoMyBusinessTricksAfterPropertyAssignement()\r\n   End Set\r\nEnd Property<\/pre>\n
\u2022 It’s a bad idea to throw exceptions inside your persistent properties. At the very least, don’t do it between OnLoading and OnLoaded (IsLoading == true).<\/p>\n
\u2022 Don’t use the Session’s Save method whenever possible. Use the UnitOfWork’s CommitChanges whenever possible.
\n\u2022 Share a single DataLayer between all your sessions within same AppDomain whenever possible. Assigning XpoDefault.DataLayer in the Main() function of your program is good style.
\n\u2022 Never do any complex work on persistent object .ctor(Session) and persistent properties assignments (at least between OnLoading and OnLoaded (until IsLoading == true)) — if you want Xpo to be effective, persistent objects must be created as quickly as possible from their Data Store images.
\n\u2022 If your algorithm requires ten persistent objects — load them all at once at the beginning of the method
\n\u2022 Never load more objects than actually needed.
\n\u2022 Use Grids and Lookups in ServerMode when appropriate.
\n\u2022 Always use IDataStore for remote scenarios.
\n\u2022 Don’t expose your business objects instances remotely, in scenarios where this is possible. Use eXpress Persistent Objects, when available, if you absolutely need to transfer objects over the wire, but think twice: do you really need it?
\n\u2022 Never use XmlWebServices until all your clients have access to assemblies provided by you. Expose IDataStore via WebService, and allow your clients to work with persistent objects.
\n\u2022 If you need to disallow your customers from changing something through remotable IDataStore — create an IDataStore wrapper, which will throw an InvalidOperationException on each call to ModifyData.
\n\u2022 Use\u00a0<\/span>Domain Model<\/span>\u00a0whenever possible.
\n\u2022 The OnSaving and OnDeleting methods of your persistent objects are valuable in two ways:
\n1. Custom keys generating
\n2. Last-chance checking.
\nDefense checks must not be violated in the normal workflow – if such a check fires, it means something is bad with your program.
\nPlease note that if you still decide to use these methods to execute your business logic, take into account that in a general case, they may be called multiple times (e.g., when an object is first saved in a nested Session and then committed to the database in the root Session or in a middle-tier scenario). This may lead to incorrect results, unless you handle this appropriately in your business logic or if multiple execution is irrelevant for it. For instance, you can check whether a value was already assigned to a property or not. Refer to the\u00a0<\/span>How to generate a sequential and user-friendly identifier field within an XPO business class<\/span>\u00a0article for some example code.\u00a0Alternatively, you can move your logic directly into dependent property setters. Refer to the\u00a0<\/span>Task-Based Help<\/span>\u00a0>\u00a0<\/span>How to: Calculate a Property Value Based on Values from a Detail Collection<\/span>\u00a0article for some example code as well.
\n\u2022 Don’t mix the process of objects saving\/persisting and business logic (including business rules validation) — this is a\u00a0<\/span>code smell<\/span>\u00a0of the\u00a0<\/span>Transaction Script pattern<\/span>. The examples of defensive validation described in the previous point are exceptions, rather than good rules. You should not use this in your applications often. The best practice is to validate your objects before the saving process is started. Usually, it should be done either right after the changes are applied (for example, property setters), or later, with the help of a specific validator class that has knowledge of the contexts, in which a business object exists and is validated.
\n\u2022 Don’t work with the same persistent object instance from different threads. Create a separate session for each thread, and work with different instances of the same persistent object.
\n\u2022 Don’t create a class structure which will result in loading half of the database on accessing a single object\/property. For instance if you have a class Gender with two instances, Gender(“Male”) and Gender(“Female”) it’s a bad idea to create a collection of all persons of a specific sex in the Gender class. If you need to do it for building criteria — make the collection property private or protected, and return null from it (undocumented and unsupported but a working and useful feature).
\n\u2022 If your class structure is highly coupled and it’s actually possible to raise a complete database accessing the single object\/property, break this net using<\/span>delayed loading<\/span>.
\n\u2022 Don’t use Delayed loading if not really needed.
\n\u2022 Don’t make your code dependent on the order of records returned by the XPCollection\/XPView\/XPCursor objects, unless you explicitly\u00a0<\/span>sorted<\/span>\u00a0them. By default, if the XPCollection\/XPView\/XPCursor is NOT sorted, records will be returned in an arbitrary order. This mimics the behavior of the SQL SELECT statement in the same circumstances.
\n<\/span><\/span><\/p>\n
See Also:<\/strong>
\n<\/span>XPO Fundamentals<\/span>
\n<\/span>K18061<\/span>
\n<\/span>XPO Worst Practices<\/span>
\n<\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
\u6765\u6e90\uff1ahttps:\/\/www.devexpress.com\/Support\/Center\/Question\/D … \u7ee7\u7eed\u9605\u8bfbXPO \u6700\u4f73\u5b9e\u8df5\uff08XPO Best Practices\uff09<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-100279","post","type-post","status-publish","format-standard","hentry","category-wordpress"],"_links":{"self":[{"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=\/wp\/v2\/posts\/100279","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=100279"}],"version-history":[{"count":0,"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=\/wp\/v2\/posts\/100279\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=100279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=100279"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.ilezhi.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=100279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}