Search This Blog

Showing posts with label ORM. Show all posts
Showing posts with label ORM. Show all posts

Monday, June 6, 2016

How to access derived (inherited) objects from OData Service

I want to quote a new KB article we created to more easily answer such user questions, especially due to the increased interest in OData in light of the recent arrival of the XAF mobile UI (CTP)

Scenario/Situation
"I created an XPO OData service (XpoDataServiceV3) based on my model, but when I try to query a collection of objects that are derived from another persistent object, the result set includes all objects inherited from the base class. Is it a bug? How can I get only derived objects?"

Explanation/Solution
"This behavior is caused by limited support for derived objects in the OData protocol, which doesn't expose derived classes as entity sets. To access derived objects or their properties, you have to include a type cast using the qualified object type name in the path constructed for a base class. For example, if you wish to get Person objects that are inherited from Party, use the following query:

http://localhost:56789/MyDataService.svc/Party/Person/



Please refer to Derived Entity Type section of the OData Advanced Tutorial and Addressing Derived Types section of the OData protocol documentation for more examples.

Note that this specificity is not related to XPO. If you create a WCF Data Service based on an Entity Framework model, it will behave in a similar manner in regard to derived entities."



And here is a real-life URL query I tested with the data service I created with our MainDemo app and the new Mobile project template:

http://localhost:51562/DataService.svc/DevExpress_Persistent_BaseImpl_Task/MainDemo_Module_BusinessObjects_DemoTask?$filter=Subject%20eq%20%27Task1%27


Again, take special note that this is however, NOT specific to XAF itself or DevExpress ORM OData Service in any way, but rather to the OData V3 protocol itself.


Monday, December 14, 2015

XPO ORM Data Model Designer and Wizard FAQ

My fellow colleague Michael has recently written an article based on the most popular support calls regarding the visual designer that XPO ships with, for editing visual data models. Some things may already be known to you, but others are worth repeating and I hope you will find this short doc helpful:



Thursday, March 19, 2015

Making sure a property value is unique with XAF and XPO

I wanted to share a link to a hot Support Center discussion on the subject (it has now been unpublished by the author, sorry) with the community members as I believe this business task is not unique:-) and many others should be interested in knowing how to properly handle this.
I am going to detail technical considerations of possible solutions at the application UI and database levels depending on various configurations of your data model including inheritance mapping options (Table per Hierarchy or Table per Type) and soft deletion.

Application UI level

First of all, let's start from the UI part. How would a developer of an XAF app ensure that its end-users are not allowed to save records whose property value or combination of values are unique? 
As you know, XAF ships with a built-in validation module that provides a powerful and extendable validation engine and a large set of predefined attributes to configure common validation rules declaratively. To ensure uniqueness, you can first add the ValidationModule component into your XAF module or application via the designers and then choose from the two built-in rules: RuleCombinationOfPropertiesIsUnique and RuleUniqueValue (it is also possible to turn RuleObjectExists and RuleFromBoolPropert for the same task, but its use is not that straightforward use and I will not talk about it for now). Depending on your preferences, you can either annotate your data model classes with the corresponding code attributes, e.g.:

       [RuleUniqueValue]

       public string Name { ... }


or declare everything at the Application Model level via the Model Editor tool (learn more...). In addition, you can configure the rule's CriteriaEvaluationBehavior parameter, to specify whether to look for modified objects that are currently loaded in memory, in addition to objects in the database itself.
As a result, the XAF's validation engine will consider the rules you configured  when a data record is being saved (technically, when the View.ObjectSpace.Committing event is raised) and will throw ValidationException when uniqueness is violated. This is a special exception type, which is caught by other system controllers to display the validation error in a nice way in the UI:




This would be our topmost  or basic protection level as it handles user input only. It will not help avoid duplicates if the same data records are created in code by a developer who did not call one of the Validator.RuleSet.ValidateXXX methods. 

Thursday, March 12, 2015

How to map ORM data model to another schema, e.g. other than the default "dbo" in MS SQL Server?

I just wanted to bring your attention to the recent update of one of the articles in our support knowledge, which is devoted to advanced data layer customizations - telling XAF business objects to use a different owner schema in the database.



Here we go:

Tuesday, December 30, 2014

About XAF Types Info Subsystem...

I have just closed the DC - Provide support for dynamic members in domain components ticket with two possible solutions (there were some specifics with regard to the late generation of real XPO classes for DC interfaces) and wanted to use this chance to draw your attention to some advanced stuff you may need one day - customizing your data model metadata at runtime via the underlying types info subsystem (ooohhh!)

In short, you may need customizations at this low level when you want to dynamically adjust your ORM data model mappings to the database, add or remove custom members for your data model at runtime (e.g., based on the info stored in the database, XML settings file or any other source) when implementing an app tailored to a specific client/user access rights, etc.

Leaving customizations aside (which is quite rare, to be honest), accessing information about the types (their metadata) registered within the XAF application is really common. For instance:

  • If you want to check what business class this View is for - check the View.ObjectTypeInfo property. 
  • If you want to check the member a PropertyEditor corresponds to - check its PropertyEditor.MemberInfo property.
  • Need to know whether a business class has a certain property? Use the ITypesInfo.FindMember or ITypeInfo.Members APIs.
  • Want to know which code attributes are applied to a class or property?  Call the IBaseInfo.FindAttributes method (check examples here).
  • Want to get/set a class property known only at runtime? Use the IMemberInfo.Get/SetValue methods (see an example in the end of this article - it's like .net reflection, but faster).


Our documentation describes this in several articles here:
eXpressApp Framework > Concepts > Business Model Design > Types Info Subsystem

I have also prepared a small schema to better explain the role this type of info subsystem plays:

As you can see from the schema, this 'types info subsystem' serves as a source for Application Model and thus UI generation. That said, in certain scenarios, you may want to access certain info at a higher level instead of accessing the types info subsystem directly.


If you are anxious to see more advanced XAF stuff today, consider reviewing my previous post at
How to customize the underlying database provider options and data access behavior in XAF.


See Also:
eXpressApp Framework > Concepts > Business Model Design > Data Types Supported by built-in Editors

Friday, December 26, 2014

An Entity Framework version of our XCRM demo

You might have noticed that starting with v14.2 we made an EF-based version of our popular XCRM show-case demo. It is installed at %PUBLIC%\Documents\DevExpress Demos 14.2\Components\eXpressApp Framework\XCRM\ by default.


Data models and DbContext code are located within the XCRM.Module\Data\ folder for you to explore. These data models are built for real and quite complex scenarios, so you can use this as a reference in addition to our two other Entity Framework demos:

  • %PUBLIC%\Documents\DevExpress Demos 14.2\Components\eXpressApp Framework\EFDemoCodeFirst\
  • %PUBLIC%\Documents\DevExpress Demos 14.2\Components\eXpressApp Framework\EFDemoModelFirst\

Thursday, December 25, 2014

Looking for practical experiences with both DevExpress XPO & ADO.NET Entity Framework


----

You know that XAF supports both ORM libraries to almost the same extent, so there is no noticeable difference at the framework level (see 1, 2, 3) that should affect your choice in favor of a certain data access tool. There are, however, some differences between these ORMs in their functionality, usability, history and other factors which may indirectly affect your choice.



We do not provide comparisons of our products with competitors (mainly from an ethical point of view), but I think it would not hurt anyone if there was a list of proven opinions from users who had practical experience with both ORM tools. I already started collecting this list and among differences our users mentioned was, for instance:

Wednesday, August 6, 2014

Forcing Boolean Property Editor to work for a string DB column

The world is not perfect and sometimes we have to deal with legacy data, which is not well organized. For instance, data which is binary by nature can be stored using predefined strings ("T"/"F" or "Y"/"N"):


Correcting data is not often possible, because this data can already be used by other information systems.
As you know, XAF automatically generates editors for data fields in the UI based on the field type in the ORM data model (learn more...), so in this particular case an inappropriate editor (text box) will be used if we leave the default mapping to a string column "as is" - a text box instead of a check box or drop down box with the Yes/No values. In this blog post I will show you several methods on how to work around this situation and have the correct editor in the UI while keeping the underlying data table schema and data unchanged.

Saturday, July 19, 2014

How to customize the underlying database provider options and data access behavior in XAF


I just wanted to repost my recent update to the corresponding article, because this information can interest some advanced XAF users.

IMPORTANT NOTE

This article describes some advanced customization techniques and low-level entities of the framework with regard to data access, which may be required in complex scenarios only.
So, if you just want to change the connection string, e.g. to use the Oracle instead of the Microsoft SQL Server database, then you would better refer to the Connect an XAF Application to a Database Provider article and documentation on your database provider instead. The XAF integration of supported ORM libraries is also described in the Business Model Design section of the framework's documentation.

Introducing IObjectSpaceProvider and IObjectSpace

XAF accesses data from a data store through special abstractions called - IObjectSpaceProvider and IObjectSpace.
The IObjectSpace is an abstraction above the ORM-specific database context (e.g., the DBContext used in Entity Framework or the Session in XPO) allowing you to query or modify data.
The IObjectSpaceProvider is a provider/creator of IObjectSpace entities, which also manages which business types these IObjectSpace are supposed to work with, how to set up the underlying connection to the database, create and update it and other low level data access options.



An XafApplication can use one or several IObjectSpaceProvider objects at the same time, and you can access this information through the XafApplication.ObjectSpaceProvder or XafApplication.ObjectSpaceProviders properties. Check out these help links to learn more on how to plug in custom IObjectSpaceProvider objects a well.

There are several built-in implementations of the IObjectSpaceProvider and IObjectSpace interfaces in our framework, which are usually specific to a target ORM (Entity Framework or XPO). I suggest you check out the source code of the default framework classes to better understand the role of the IObjectSpaceProvider:
...\DevExpress.ExpressApp.Xpo\XPObjectSpaceProvider.cs
...\DevExpress.ExpressApp.EF\EFObjectSpaceProvider.cs