Why you should not use Devexpress XAF for midsize projects

In this short post I want to share my personal experience with Devexpress XAF (eXpressApplication Framework). The preface is - you think that this "famous magic box" can help you to build high class enterprise - scale software system. Because XAF has rich "modules". Because it targets Windows desktops and ASP.NET "platforms". Because it has online docs and the user community. Did I miss something? Oh yeah! Case studies and user comments... A lot of them are connected to XAF and might make you sure that XAF is the "magic thing" you are looking for...
OK, let's look inside of that super thing. The library (or framework) you use should be reliable and high performance. Otherwise your customers have to buy new computers (or servers).
1. Memory leaks:
http://www.devexpress.com/Support/Center/Question/Details/Q444882
http://www.devexpress.com/Support/Center/Question/Details/S39277
Our application has over 40'000 lines of C# code and the built application could occupy over 1GB of the computer memory (!!!!???) during some hours of user activity in the XAF application. GC doesn't help.

2. Ugly Insecurity:
In case you built an application connected to any type of SQL database service (MS SQL, Oracle etc.) you have to:
1. take care of setting security to each role of users inside the database (add users to logins and roles) OR provide full access to the database to all XAF application users.
2. you have to set users and roles in your XAF application to hide protected functions.
In order to prevent users to have direct full access to your database you have to build mid-tier application service:
http://www.devexpress.com/Products/NET/Application_Framework/features_middle_tier_service.xml
Read the page: "XAF applications can now obtain data from the application server, thus preventing the client application from direct database connections. "
In other words XAF security is a kids' toy and admins' headache if you do not use an application server!

3. Unreliable code of modules:
Workflow module is unreliable. I tested Workflow with hundreds of runs. From time to time it doesn't resume "Idle" processes if you restart Workflow.

4. The XAF application is extremely slow.
We have computers with Intel Core i5 and i3 CPU and 4-6 GB of RAM. Our XAF application starts in 15-25 seconds. Any XAF "view" appears in 100 times slower then classic "Windows Forms" or ASP.NET page. If you have low-end "Celeron" or "Atom" CPUs it is a real pain.

_____________________________________________________________
The verdict is: avoid Devexpress XAF in your upper-beginning enterprise projects. It is good idea that is not mature yet. Use cross-platform JavaEE + GWT, Python + Django. Or pure ASP.NET for Windows only.

QA!

Recently I see QA growth in software industry. I like it. It is a positive trend. Do you know good QA in Moscow? E-mail me! I need them!

Deluge on the South of Russia

Hello everybody,

Despite the huge deluge in Krasnodar region we all are OK. Soon we will be back in Moscow.

Devexpress XAF and enterprise projects

Recently I had an opportunity during some months to evaluate Devexpress eXpressApp Framework. Here are some my thoughts.
1. It is very easy to build a prototype, especially by one developer.
2. It is easy to impress bosses and your customers with the nice look-and-feel interface and out-of-box features.
3. It is tight Visual Studio - integrated framework and it brings to you (and to your team) some feeling of reliability and comfort.
4. But ... it is huge headache for the entire team to work with all design features (forms, action buttons, lists etc.) in the single .XAFML file!!!

Decades of development taught developers to split user interface (UI) and software logic apart. Then almost all IDEs were built with a idea to separate UI in small files, it helps a lot when you have more then one UI designer/programmer. But Devexpress decided to put all application UI into a single file! Thats really some kind of stupid way to help software developer teams to split UI tasks... Now eXpressApp Framework developers have to merge their local .XAFML files (actually big XML file) with other developers. In my experience this "Devexpress progressive approach" caused lost many UI works during the entire period of development process. The way how Visual Studio 2010 merges XAFML files and then eXpressApp Framework builds the application is a real nightmare: some XML chunks are thrown away of XAFML file and your team has to loose time to reconstruct the UI...
The Devexpress docs say that you can split the solution by multiple purpose-driven projects and edit UI in XAFML in each of them. But still there are some features (splitters for example) that can be used only in the main .XAFML (startup .EXE file). That is very sad :-(

So we don't have the solution for eXpressApp Framework UI merges yet. I hope that others who use Qt, Witty, ffead or Dijango can avoid that problem.

Terminal Server Solution for Single Instance Application

I used the code from  this article  in order to add a singleton property to our software. Later I modified the code for Microsoft Terminal Server mode, see the new C# code here: http://www.codeproject.com/Articles/15185/Single-Instance-Application-Passing-Command-Line-A?msg=4226976#xx4226976xx