It's been pointed out, from Jesper on this same blog(see previous post's comments) and in several Borland forums(and during 24hrs), what ECO really is.
ECO is, simply put, a new way to write applications. It has all the features of an OPF, plus a powerful constraint language, OCL(which is common practice in the MDA world), which is
meant to make the life of us programmers easier.
The most compelling reason to use ECO, then, is the fact that a fair amout of code(namely: all the persistence code) gets out of the way to let us concentrate on coding the application.
There're other reasons, too, though: for example, you can use your own already existing database that you can evolve to use ECO.
You can also(you most times actually will) model your business classes and map them onto one or more persistence layers(I'm talking the full blown ECO here) directly from inside Delphi.
This means that, if a customer asks for an Oracle database, oplà, tell ECO to use Oracle and you're done.
As you can see, these are all extremely good reasons by which you'd want to use ECO.
There's one main issue here though: ECO is about dotNET, not Win32. This means that you'll have to use it in a managed environment. This might not be what you really want from your
apps, especially when you're not server side.
This becomes really especially true if we're also considering that DeXter Pro will contain just one persistence layer instead of multiple: the XML files.
This is indeed a problem. Assuming you might want to take on the risk and try to deploy to desktop PCs, you're facing the "Win9x challenge": will my application just run somehow or
won't it even start?
Please let me remind you(is it really necessary? Hope not!) that the average computer user is plenty full of viruses in his/her machine and that Win9x is unstable most of the times and with very poor hardware dotation(little RAM, little HD, etc). You might trying by limiting your app to Win2000+ but then... computers running Win2000 are still below actual computer horse power(not as much as Win98 machines, but... well you get the idea!). Are you sure that it's going to run smoothly and without problems? Obviously not(I'm talking about "structural" problems which are not to be raised by single applications). I've collected some informations at the 24hrs of DeXter, where an ECO team member told me that, by itself, this library doesn't add up very much to dotNET requirements, but still... thus, the only "reliable" option is to limit to Windows XP. Not only that, but you must make sure that you have enough RAM(please read Mark Russinovic's post about dotNET applications memory usage!) and decent hardware components
(big HD, etc).
Now, on to the technicalities about dotNET. You'll end up choosing WinForms or VCL.NET .
Either one, to me, doesn't seem a great option. Why? The (in)famous JIT compiler. Why this is a problem is *very* easy to understand: dotNET is precompiled in IL code. This code then gets translated on-demand when you're going to use it. Lastly, it gets cached till you close the application. This means that if you restart your computer or anyway close the application, the next time you'll have to go through JIT again! Now, given how many times you're bound to restart Windows(just think of the updates, let crappy software apart), you can see where the problem is.
Let's consider something relatively "simple" in dotNET: managing XML files. These are usually managed through DOM rather than SAX, because you will normally need the tree. At least, I still have to find a situation where I didn't need the tree. Maybe XSLT transformations are better off with SAX, but I don't do that usually ;-).
DOM engines for XML all suffer by one element, which is critical in dotNET applications: Memory consumption. Small files(in Win32) already get to use a fair amount of memory, let alone big ones. Go figure in dotNET. Plus, the code to load them is fairly slow(keep in mind
that XML files might be using several different encondigs, thus a parser has to check for
encoding compliance and so on - and they can't just assume you're using UTF-8 and it has to check for each node and for all its attributes, be it leaf or not).
Another problem, is that dotNET doesn't have pointers. Yes, I know, that's supposed to be a "feature", yet I like pointers :-) because they speed up some of my work. All Delphi classes are "pointer based"(actually that's what you're managing when you write var SL: TStringList, since the compiler will translate that to var SL: ^TStringList) and there're a few third party components that make a brilliant use of Pointers(Virtual Treeview being the one that comes to my mind first). Such components can't be ported to dotNET(obviously) and that's a problem for Delphi programmers, since many of them are using that and other components that can't be translated easily to be managed ones.
These are just a few of the problems that you may encounter in dotNET. But we were talking about ECO, now let's see some "ECO-specific" reasons by which you won't probably want to have ECO desktop applications. ECO makes use of WinForms and if you've explored some more detail about it(I'm a Delphi 2005 user) you'll have discovered that you can't include WinForms code straight into your applications the way you used to with Win32 packages. You can - instead - do that with VCL.NET . This means, basically, that if you want to deploy such applications to the market, you have to deploy ECO packages too. This means - potentially - that if I'm a D2005 user and I download the demo for free I might be able to add ECO packages in the IDE, thus having access for free to something I would have to pay for otherwise. Now, how am I going to make sure that you don't have Delphi 2005? I can't - clearly. This means I can only do components which expose some ECO persistence property to work, but this also means that I have to restrict my market to components development that will be used by a vastly reduced market, namely D2K5 Architect owners and upcoming DeXter owners. The other way you can safely use ECO for the time being is ASP.NET applications. You build a website, then let users subscribe to your services. With Highlander, this is apparently bound to change - because ECO will be available for VCL.NET which is a good thing.
Starting to "see the light"(at least, what I think to be such) now? :-)
Thus, the problem really boils down to what you're planning to do with it.
There're advantages too, such as the fact that even if you have DeXter pro(making components), that counts very little: just expose the correct properties and anyone using ECO would be able to change the persistence mechanism, even though you can only provide XML persistence. If you're writing webservices, you can however detatch your ASPX service from ECO persistence and be good with it. Actually, if you have a set of classes that "hide" ECO to the service, this seems very good to me :-) You can however upgrade if/when the website is having enough subscribers, till then you might have separate XML files(where appropriate) for each user.
See, all this actually makes the "right decision" fairly difficult to do, considering all of the above.
I don't think to have the Truth in me, thus I'll just tell you what I would do if I had to choose.
My best bet would be to go for components, because even if the market for them is fairly shrinked, managing, updating and advertising a website can be quite challenging, while a message on Borland Forums now and then to advertise your components would probably suffice for most businesses. Also keep in mind that managing a website offering a subscription service must be done on reliable hosting - maybe redundant? - plus you also have to improve the service itself, leading to potential problems with customers who don't like the service's changes,
while component customers can simply stick to what they already have without upgrading.
Once ECO will be in VCL.NET, though, this all might(and probably will) change.
Cheers,
Andrew
No comments:
Post a Comment