Idle Musings of a Delphi Junkie

I'd love to have ECO support VCL.NET, and was ruminating over this fact yesterday, when a thought dawned on me. The only thing that really makes ECO a WinForms technology is its support for .NET WinForms binding via the Reference/Expression/CurrencyManagerHandle components, and the EcoAutoForm stuff. The other underlying services and frameworks are not really dependant on WinForms at all.

For the life of me, I can't see why it wouldn't be feasible to use VCL.NET as your presentation framework, and still have full access to the EcoSpace IPersistenceService, IUndoService, IDirtyListService, IOCLService etc. The only thing you'd lose is the ability to have your domain objects bound to your GUI, which isn't really a big deal to me as I was in the habit of manually populating from my BO classes with my last few projects anyway. Hang on...

type, type, compile, mumble, type, compile..


OK, now I've quickly thrown together a prototype to test my theory. It uses the assembly containing the model that my currently under construction WinForms and ASP.NET ECO apps use, and simply shows all instances of the Course class from the model in a TListView. It does, however use a PersistenceMapperClient to talk to my ECO server application, and this all worked out of the box (as expected). If anyone is interested (or actually reads this blog for that matter), feel free to contact me and I can send you a copy. Alternatively, it was posted to the borland.public.attachements newsgroup, but be warned that posts there have a limited shelf life.


Its only a proof of concept thing, but seems to strengthen my belief that there is no reason why ECO and VCL.NET are mutually exclusive. It only has the code for the VCL.NET app, and includes the binaries for the assembly containing my model, and for the ECO server (connection hardcoded to tcp://localhost:8000/PocketCaddyServer). The ECO Server has a PersistenceMapperBDP which is talking to an InterBase database with the hardcoded path of POCKETCADDY.GDB (also included in the zip), but I see no reason why PersistenceMapperXML couldn't be used in the VCL.NET client for testing. I only chose to use my ECO server to further re-inforce the whole proof of concept deal.


And since coding this app, I've had confirmation from the ECO architects that there is nothing wrong with this plan at all, and the only thing you lose is support for databinding to your GUI. So if that isn't really an issue, there is no real reason to not use VCL.NET for ECO apps today.