Greetings,1. Leverage existing developer experience and expertise as well as 3rd party tools to minimize development time.
I am in the process of making decisions regarding the future direction of a mid-size (around 100 tables some with millions of rows) WinForms enterprise database application. I am looking at several DevExpress technologies (we're a long term satisfied user of your WinForms controls). Specifically we are looking at XPO, XAF and your MVC controls. Our goals are to:
2. Isolate database and business logic on the server side (most logic is the monolithic WinForms client app)
3. Preferably support an open source server stack (mono/postgresql)--need DB independence.
4. Support a variety of client platforms (iOS/Android/Web/Desktop) while balancing (a) reuse of client code as efficiently as possible between platforms with (b) providing a natural (somewhat customized) UI interface on each platform.
Currently, we use LLBLGen Pro as an ORM and are happy with it. We have quite a bit of experience with MonoTouch and Mono for Android which allow us to reuse some client code in mobile devices. We are looking at moving business and database logic to the server and exposing it through WCF OData (or possibly some alternate mechanism). We currently use DevExpress WinForms controls on in our desktop application. We are exploring ASP.NET MVC on the web side. A few questions I have:
5. OData binding. Can I bind all DevExpress controls to OData data sources? If not which controls can be bound? Does platform make a difference? For example can I bind WinForms Grid as well as ASP.NET MVC Grid? How does the binding mechanism work? Does it require XPO? What is performance like? What special issues am I likely to encounter in using OData? Can DevExpress controls consume XML or just JSON?
6. Data Layer generation. Is there anything special about the XPO generated OData data sources or could I use my current, preferred ORM (LLBLGen Pro) to generate my OData layer and then bind the DevExpress controls to it? Would there be advantages to using XPO over LLBLGen? What would those advantages be? Does XPO do auditing, authorization, validation?
7. Business logic. If I use XPO to generate my OData service layer is their a mechanism for including custom business logic in this layer? CRUD operations are somewhat complicated in our application and inserting a record in one table may require modifying data in several others to maintain consistency. Most of our business logic we would like server side -- not sure how best to do this with the OData model.
8. Database independence. We need to support multiple databases to conform with our clients preferences (SQL Server, Oracle, PostgreSQL).
9. XAF. Can XAF work with OData data sources or other web service based approach? Does XAF require XPO or could another generated OData layer be used with XAF? How do XAF and DXtreme relate to one another? How about ASP.NET MVC--can XAF work with that? Are XAF ASP applications compatible and fully functional within a wide range of browsers?
I appreciate feedback or comments from both DevExpress and other developers who may have experience with these technologies.
I apologize for keeping you waiting. Here are answers to your questions.
A1: Yes, you can. Our controls are not relevant to OData or any other data source type. For instance, you can bind a grid to any IEnumerable data source.
I should say that our controls use the standard .NET Framework binding mechanism and you can learn more about its features and specifics in MSDN. The same goes for OData itself, its performance and issues, since it is not related to our products at all.
Our controls can consume XML (e.g., via standard data sources like XmlDataSource) or JSON, because as I said above, you can bind any IEnumerable list to them.
There are, however, some built-in components like WcfInstantFeedbackDataSource that soften your data-binding task.
Correspondingly, our controls do not necessary require XPO, although there is a number of built-in components for this ORM.
A2: There is nothing special in OData generated from an XPO data model as it conforms to OData standards. You are not forced to use XPO and can use your own ORM with our controls.
I do not think that there will be any advantages of marrying XPO with your current ORM.
XPO does not provide built-in validation, authorization and other features itself. It is implemented on top of it in our eXpressApp Framework product.
A3: It is possible to include a custom business logic into this service like it is possible with any other WCF Data Service. You can find more examples on this in MSDN. As for XPO examples, check out this blog for an example of a custom logic (IsGranted, CanReadMembers) in the CustomAuthenticationDataService class. It is also worth noting that a custom logic is also present in another tier, technically in the CustomWcfSecuredDataServer class that is used to keep security checks (it can be extended to run additional business logic as well).
A4: This is the key feature of XPO. You can learn more about it here.
A5: At the moment XAF cannot connect to an OData data source directly. There is however a technical possibility for this, but we do not have any documentation or examples on this. So, I would rather answer 'NO' this time. XAF can be used with both XPO and Entity Framework simultaneously.
XAF and DXTREME are two different products that are not integrated with each other at the moment.
XAF does not support ASP.NET MVC at the moment. Its Web UI is currently based on ASP.NET Web Forms. In any event, XAF supports all modern browsers.
A6: No, you cannot use C# with DXTREME. As for advantages, DXTREME comes with many built-in widjets like charts, grids, etc. and provides a rich design time experience for its developers. You can learn more about its advantages here. Since DXTREME is based on PhoneGap, you would better compare it with the competitor product: https://www.google.com/search?hl=en&q=monotouch+vs+phonegap
To sum this up, it is technically possible to accomplish the tasks you are looking for, but at the current stage it may be difficult as we are improving our middler-tier to make it more usable for developers and to support a wider range of scenarios. So, in the meantime probably it would be better for you to implement these tasks manually using solutions provided by the Microsoft stack rather than by our framework, unless if you are ready to research the XAF source code and work without a complete documentation on the middle-tier application server.
Do not hesitate to contact us in case of any further questions.