Re: What multi-tier components to use
- From: "Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau>
- Date: Fri, 20 May 2005 10:32:54 +1000
Hi Herbert,
> I like kbmMW because it just works.
Well, that's after you've been through the learning curve. <g>
For example, in my experience I had these issues
* its resolving functionality never 'just worked' for me because its error
table never worked like advertised in the help and the white papers (which
suggested the error table would contain a list of errors, but in actual fact
the system dropped out at the first error and I had not been led to
anticipate that so had to rethink my app architecture).
* I initially had plenty of trouble with the versioning functionality.
* How to set up services was poorly documented.
However, Kim's support and the newsgroups were very helpful in moving
through these issues. Having got through all these issues, indeed 'it just
worked' for what I wanted it to do.
I think that perhaps 'it just works' is a perspective that you have _after_
you have acquired familiarity and comfort with the product and been through
the learning curve on its 'gotchas' and pitfalls.
> I'm also comfortable with its level of
> abstraction. There are certain areas where I can accomplish an incredible
> amount very easily without really needing to understand what's happening
> "under the covers". But with any of these products there are times when
the
> framework doesn't do things exactly like you want. When that happens it
> feels very comfortable to go "under the covers" with kbmMW. Also, the
kbmMW
> source code is elegantly written and an education in itself. I am nowhere
> near as familiar with RO/DA, but its level of abstraction feels higher
than
> kbmMW. This could be partly because RO/DA has some nifty GUI tools that
> integrate well with the framework, but which I haven't really missed with
> kbmMW.
I found both kbmmw and RO/DA had significant learning curves, but very
different in nature.
I think once you get familiar with RO/DA, you can do the basics *very*
easily and reliably, and you can then extend it in a flexible way.
I think RO/DA is more 'structured'. As you pointed out at another time, this
is a disadvantage when you want to modify the database structure on the fly,
but otherwise I generally find the framework much more structured, clearer,
and more reliable and its a good thing.
Particularly with regard to services.
I think you can use RO/DA productively in a RAD drag and drop kind of way
without knowing anything about interfaces. You just need to be able to use
the Service Builder (RemObjects | Edit Service Library) to define your
services, and then you can call them remotely. In DA, you need to use the
schema modeller, and learn a little about the login framework if you need
that, and again you can code solid n-tier apps without knowing anything
about interfaces.
Generally, I agree that RO/DA is archtiected at a more abstract level, but
you don't have to face up to that abstraction when getting going.
> kbmMW currently has potentially large advantage (I believe) over RO/DA in
> that it supports true messaging (not the event-polling kind) and as part
of
> that technology advantage I believe it also has better support for
> asynchronous requests. I think RO/DA is planning to add a similar sort of
> messaging in a future release, though. If you think you may need
messaging
> support as part of your n-tier app that's something you should check out
> carefully before you choose which framework to use.
I gather this is the case, but I've only heard the case made by the kbmmw
team! <g>
What specifically is the disadvantage with the event-polling approach? The
delay as you go through the central server?
In any case, I should point out that the area of RO's greatest strength in
comparison to kbmmw is in services. If a service oriented approach is
required (and this seems fundamental to n-tier to me) RO has very clear
strengths in that area.
> RO/DA does have more polished and complete documentation. Both products
> have active newsgroups with good support from both users and from the
> component vendor/author.
Indeed.
I thoroughly agree with your comment that they are both solid products with
excellent support, and I suggest that people looking for an n-tier solutions
should evaluate both and visit both newsgroups to find what suits their
needs best.
Oh, I'll also add that both products either have or are very advanced in
providing full .net support as well.
Lauchlan M
.
- References:
- What multi-tier components to use
- From: Petros Amiridis
- Re: What multi-tier components to use
- From: Uffe Kousgaard
- Re: What multi-tier components to use
- From: Herbert Sitz
- What multi-tier components to use
- Prev by Date: Greatis Runtime fusion + tms scripter sample
- Next by Date: Re: Zip component
- Previous by thread: Re: What multi-tier components to use
- Next by thread: Re: What multi-tier components to use
- Index(es):
Relevant Pages
|
