XPO now has support for Linq. Entity Framework also has this kind of support.
It would be nice to be able to use Linq with IObjectSpace.
Core - Make it easier to obtain IQueryable<T> collection through IObjectSpace for LINQ
Answers approved by DevExpress Support
We have implemented the functionality described in this ticket. It will be included in our next update(s).
Please check back and leave a comment to this response to let us know whether or not this solution addresses your concerns.
The IObjectSpace interface now declares the following method:
C#IQueryable<T> GetObjectsQuery<T>(Boolean inTransaction = false);
This method is implemented in the XPObjectSpace, EFObjectSpace and NonPersistentObjectSpace classes.
The inTransaction parameter has effect in XPO only and enables the mode in which querying a data store for objects includes all in-memory changes into query results. Also, take special note that this method does not currently support Domain Components (DC).
In the NonPersistentObjectSpace, the GetObjectsQuery method casts the collection of objects created in the ObjectsGetting event to IQueryable and returns the result.
- v15.2.4Download Official Update
Hi!
There have been few releases since, but I still don't see this feature. Didn't test new 15.1.8, but nothing in changes list regarding this.
It's not a deal breaker, of course, since it's easy to implement this manually, but it would be nice to have it, especially since it's implemented.
Regards,
Mario
@Mario: This feature is available starting with v15.2. Please wait a few weeks to test it or implement a simple custom solution (see above) today. Thanks.
Hello David,
Specifically what of support do you need here? Am I correct that you would like to avoid using a CriteriaOperator in the IObjectSpace methods?
I am trying to learn more about your business requirements, and it would also be great to know four things: 1) How often do you face such a requirement and for which concrete scenarios? 2) What are you currently using to fulfill this requirement or how do you work around it? 3) If you have a temporary solution, what are its implications in terms of cost, time and resources? 4) Exactly how you would like this to be implemented? (if possible, give some concrete examples of the proposed API).
Hi Dennis,
Yes I want to avoid the CriteriaOperator as much as possible.
The main reason I want to use Linq inside my XAF application is the (compile time) type safety it brings. But I don't think I need to tell you the advantages of Linq…
We rename our properties a lot during the development of new features and it is difficult to do so when we have to use CriteriaOperators.
Since XPO started providing XPQuery we started using it, first to transform to CriteriaOperators and later directly using (at that time our own) extension method Query<>(), this worked very well for us in an application that only used XPO. In our XAF applications we started to add the following extension methods:
[code lang="cs"]
public static Session GetSession(this IObjectSpace objectSpace)
{
return ((XPObjectSpace)objectSpace).Session;
}
public static XPQuery<T> Query<T>(this IObjectSpace objectSpace)
{
return objectSpace.GetSession().Query<T>();
}
[/code]
I know this will provide problems when the objectspace is not an XPObjectSpace, but it works for us at the moment.
My proposed API would just look like that:
[code lang="cs"]
interface IObjectSpace
{
IQueryable<T> Query<T>();
IQueryable<T> Query<T>(bool inTransaction);
}
[/code]
Where the XPObjectSpace will return an XPQuery object and the EFObjectSpace an ObjectQuery. The NonPersistentObjectSpace will probably throw an exception, or an empty collection when the return type of Query<T>() will be IEnumerable<T>…
I appreciate your detailed reply, David. Just wanted to be sure where are understanding your requirements correctly.
I will use the David's solution on my commercial project, so I'm interesting that this 2 methods will be implemented at the core level.
Hello Stanislaw,
Thank you for your feedback. We will certainly take it into account when planning a time frame for this feature implementation.
This would great, I also try to find any alternative to using criteria as strings.
Just like David says, development brings a lot of changes and renaming and when things get big, lot of time is wasted in debugging those string criteria.