Hi, I would like to establish a list of pros/cons that people are aware of when developing client side software in either the new GUI for .NET route against a native .NET client application using the Open Client for comms with the AppServer/Database.
Please provide any feedback in terms of pros or cons you have experience when developing a client in either of the technologies.
Thanks in advance
Mark Dearlove
Please provide any feedback in terms of pros or cons you have experience when developing a client in either of the technologies.
The biggest con of GUI for .NET MIGHT be the lack of multi threading. It's not supported by the Progress client and not supported (disallowed) by Progress - for most applications that's not an issue. But it may be limiting when you need to develop close to the hardware level or messaging interfaces. Some API's here expect event handling to happen in a separate thread.
But for most business applications this is not show stopper. And most .NET applications are written single threaded as well, especially for the UI. For processing you could still use async AppServer requests to "simulate" a second processing thread.
The pros of GUI for .NET are certainly the fact that you and all team members don't need to learn a new language. ABL with OO features (and trilliards of .NET objects used) may seem like a partly new language, but still it's the good old ABL.
That usually makes it very easy for a single developer to develop and debug code. I've been involved in projects where a large application was developed with a .NET client and OpenEdge backend. Basically to do any kind of integration testing and debugging two developers were requires most the time - because only a few programmers were equally qualified in ABL and C#. That may be an organizational issues. But I've experienced that this can be rather critical for many ABL development shops.
GUI for .NET offers migration options that are not possible with a .NET client just having access to ABL code on the AppServer. A proper architectural separation between UI and BL is not a must (although it's highly advised). You can run classic ABL screens and GUI for .NET screens side by side and embedded into each other (both ways!).
This may or may not be very relevant for your adoption strategy: It basically allows you to deliver .NET screens as part of the ABL application during the migration period and not just when you are finished.
Your current Progress source code structure can play a big part. OpenClient is very good when you already have SOA oriented source code structure from the get go. Creating that infrastructure is not a simple task.
There should probably be a footnote in here about Web Client as it significantly alters the deployment picture for an ABL GUI for .NET solution.
To me, it seems like the big issue in the choice is getting to continue to write all code in ABL versus having to become proficient at .NET. That is only half true, of course, since one needs a really solid understanding of the controls that one is using and that is a large part of learning a pure .NET solution.
Also, if one is considering Open Client, then one needs to consider carefully whether .NET is the right choice since it is limiting ones deployment platforms. Java client gives you more deployment options and an RIA browser client (WUI) gives you even greater deployment flexability (unless you program for IE9, apparently) and lightens the deployment issues significantly.