Re: Opinions needed about the best "Middleware suite" kbmMW vs. RO\DA

From: C4D - Kim Madsen (kbm_at_components4developers.com)
Date: 11/17/03 

Date: Mon, 17 Nov 2003 20:53:19 +0100

Hi,

Ill *** in here, not to be objective :) but to try to give you some additional info for your main questions/concerns.

> 1. Cross-db option that both offer, so which framework is better suited for
> this?.

kbmMW supports cross db in such way that all you need to do in your application is to set one property to switch to
another database. You can also support multiple concurrent databases within the same application at the same time, and
even update several databases in one go under transactional control.

> 2. I'm trying to figure out if those framework would give any boost to
> performance for say an enviroment of about 20-30 users, since my app is
> already using Chached Updates. (I guess the answer for that would be "just
> try it yourself", but its hard for me, since those users are not in my
> personal network, they are just clients using my app)

There are several factors in performance... which apply to your application will have to be tried, but generally my
experience is that the absolutely majority of well designed n-tier applications run just as fast or faster often using
less ressources than a traditional C/S setup.
What one have to concentrate about is minimizing the amount of data moved from the app server to the client. Often its
not necessary to move large amounts of data to the client. Instead one should do all the calculations etc. on the app
server and only move the result to the client. However sending hundreds and even thousands of records to a client is
usually no problem at all.

C/S setup's usually have a quite active chatter going on between the client and the database, and its usually not
compressed or secured. Using an n-tier setup, the chatter would still happen between the database and the app server,
but under much more controlled settings, and since the app server and database usually is placed relatively close to
each other on the network the penalty for the chatter and non compression is not too big. Between the app.server and the
clients, the chatter is however minimized significantly, and the data moved can be compressed and secured.

Most C/S setups have at least one connection to the database open at all times, regardless if its needed or not. The
time taken to open a new connection is often simply too long for it to be acceptable to open and close the connections
when needed. This is solved by a n-tier like kbmMW in the way that database connections are obtained when needed, and
shared between all the requests issued by the clients. The clients themself do not have any direct connection to the
database. This often highly improves performance, since it minimizes the ressources needed on the database.

kbmMW is also capable of caching both resultsets and metadata on the client for frequently used queries/stored procedure
calls (developer selectable), and the same on the application server. This can severely reduce the number of requests to
the database.
This is ofcourse not of great value for queries which needs 100% up to date information and where the data in the
database often changes, but often applications have a set of queries on data that doesnt change as often as other data.
In that case, one can benefit of resultset caching. You can at all times request an up to date resultset and overrule
the cache if you want to.
Metadata caching is on the other hand recommended to turn on at all times since this will as minimum half the number of
requests to the database.

> 3. I'm making heavy use of identity fields of sql server, they serve as my
> primary field, would they get refreshed when record gets posted to the
> server?.

kbmMW v. 2.00 contain a completely new functionality called sequences. They operate with the databases
sequences/generators or emulates those via a pivot table automatically. Using these you can pull a identity value and
post it. Its the most safe way to ensure that the identity value is in sync on the database, the app server and the
clients.

> 4. What about master detail, where the primary field of the master record
> (as noted above) is of identity type, how would they relate to the detail
> records, since I wan't them to be posted as one transaction, so I don't get
> the master primary id until the master record is actuall posted to the
> server. I did implment it myself for the sdac dataset, but I would like to
> know if there is an official implementation for this, as well as "Cascading
> updates" like ado.net, and cascading delete, so if you delete a master
> record it deletes all detail records, and of course when you apply the
> updates to the database, it deletes first the detail records then the master
> ones?

kbmMW supports master/detail in several ways (we have a whitepaper about it on our site). Again the most safe way is to
ensure that the identifier for the master record is obtained as a seperate request, and then used subsequently. It can
result in holes in the id if an identity number is obtained but not used of some reason, but that shouldnt be a problem,
as the purpose of the ID is to uniquely identify a record, rather than an invoice number. Invoice number handling can be
handled by a seperate sequence or an autoinc field and would not affect m/d setups.

Cascading updates is certainly possible to do, but kbmMW do not currently have any build in support for it as such.

> 5. How do they work with calculated?. well, one of the main purposes of
> n-tier is (noted on kbmMW's site) is that you have all your bussiness logic
> on the middle tier, so it could be used with diffrent types of clients. how
> does this apply to calculated fields, that should be calculated on client.
> For Instance, calculating an invoice line item total, that should not be on
> the server bc that keep un changing due users selections, eg qty, sales
> price, sales tax. ect.., but if you put it at client side you loose the idea
> of n-tier, and in a big app there many intances that this could apply.

On kbmMW, you can create your calculated fields on the server side, and they will be known to the client.
Everything in the world is about making the right choise for what should be placed where. If the calculated field is
primarely for presentation purposes, it can just as well be placed in the client.
The app server should contain all business code. That includes SQL, major calculations, data persistency functionality
and all types of code/data on which there needs to be some kind of access control.

> 6. What about if you have diffrent sql for insert/update/delete/refresh,
> which I make heavy use of in sdac?, are you able to use (if you want) and
> default sql, where the it autamaticly creates the sql (for
> update/delete/refresh) at run-time, and of course when you want to put your
> own sql you could. Or for each update/delete you have to enter in manually?.

kbmMW supports automatically creating needed SQL statements, even automating updating multiple tables for example in
relation to a join etc. On kbmMW you use a resolver component which is responsible for operating the backend datastore
with regards to automated updates. You have full control over the resolver, and can very easily create your own to do
completely custom work.
The resolver dont even have to operate a database, it could just aswell operate against any datastore, like file
systems, mail systems etc. The client would just see it as any normal database.

> 7. What about when you do some update to the database on a record, could you
> supply some additional sql's that should run when you do database updates,
> for instance when you create an invoice, and you want to update the
> inventory table, could you do it in one sql (like a sql scripts), which is
> how how do it in sdac.

Yes, you can easily use the resolver's insert/update/delete events to do additional work on other tables which you want
to update.
kbmMW v. 2.00 further supports some rather cool multistatement features which are under transactional control.

> 8. This is my main concern, one of my main goals of going to n-tier, is to
> have a centrilized place of placing, all business logic as well as my
> formating (attributes) of my fields, like caption, alignment, size ect.,
> well my main question is about the "formating part", how does this happen?,
> let say I have a customer table where I setup all attributes for this table,
> and I have there a field let say "CustName", and I give the caption
> "Customer Name", now I want that whenever I use this field in my
> application, but how would I accomplish that when I need a grid that its
> data is combined of joined tables via sql?, how would it get the caption of
> the field "CustName" so I dont' have to supply again the caption?

Formatting is really GUI stuff, rather than business code stuff, and thus should be placed in the gui part of the n-tier
setup which is often the client itself, or if its a web application on the web server.

However there is nothing to hinder that you have a central storage from where you fetch all those attributes/properties.
If you want to make it even more fancier, you could (for normal gui clients) combine it with one of the existing
toolkits which allows for runtime property inspectors and form design (ala what you can find on www.dreamcompany.com).
Then you would even be able to allow the client to make modifications to the layout.

> Sorry for this lengthy message, but this is actually want to know, if both
> or any of those frameworks offer those stuff.
> Thank so much for you help

Im confident that kbmMW would work great for you. 

-- 
best regards
Kim Madsen
kbm@components4developers.com
www.components4developers.com
The best components for the best developers
kbmMW          - RAD n-tier
kbmMemTable - High performance memory table
kbmWABD      - RAD web development
kbmX10           - RAD house automation