Re: Remobjects v KBM
From: C4D - Kim Madsen (kbm_at_components4developers.com)
Date: 02/20/04
- Next message: C4D - Kim Madsen: "Re: Remobjects v KBM"
- Previous message: Kevin Powick: "Re: Good HD disk space use analyser?"
- In reply to: Lauchlan M: "Re: Remobjects v KBM"
- Next in thread: Lauchlan M: "Re: Remobjects v KBM"
- Reply: Lauchlan M: "Re: Remobjects v KBM"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 20 Feb 2004 07:00:10 +0100
Hi Lauchlan,
> In DA, you can define a dataset abstractly, for example a dataset
> 'customers' could be abstractly defined, without reference to any actual
> tables or fields in actual database servers, say by defining fields
> customerID, CustomerFirstName, CustomerLastName, and CustomerPhoneNumber.
> Then, connections can be created to say SQL Server, Oracle, Interbase and
> NexusDB databases, specifically to tables within those databases which have
> fields analogous to the above (not necessarily with the same name). Mappings
> can then be created from the abstract dataset definition in 'customers' to
> actual tables in each of the above databases. This is all visually very RAD
> in the schema modeller.
In kbmMW you actually have the same posibility of abstraction or rather in reality you have _two_ levels of abstraction
with regards to the actual SQL statement.
One on the client side and one on the server side. We dont call it abstract datasets, but rather macros.
Hence you can name all SQL strings you want to, and instead of using the SQL directly in the query components, use the
macro name.
This is possible to setup on each connection pool, to ensure cross database handling easily via the cross database
adapter.
Further on the client side you have the same abilities, with the extra 'thing' that the client may replace some macros
with some other macros.
All macros not defined on the client will automatically be handled by the server.
> > > Both the server side and client
> > > side things follow from the abstract definition you start with, whereas
> in
> > > kbmmw you choose appropriate server side and client side components and
> > > hook/code them up appropriately. So architecturally, it does not seem to
> me
> > > to be as driven by the central abstract definitions (of data, services).
> >
> > Well.. in kbmMW I suggest people to not use client side SQL of abstraction
> reasons, but instead use what has been
> > defined on the server using the named query setup.
>
> And security reasons! <g> But I don't think doing the above in DA involves
> client-side SQL. What you do is retreive a dataset from the server using a
> service you code for that. In the server-side implementation of the service
> you don't necessarily explicitly use SQL directly either (but code it
> implicitly - this makes your code not be database connection specific). The
> way this works and why it is good are detailed in the public DA web articles
> DA01 and DA03 on the remobjects website.
ok.. but that is something kbmMW has been able to since day 1 too if I understand you right.
You dont have to specify any sql on the client side, or any name of a query for that matter.
You can choose to refer only to a service, and that service will have a setup which means it will always let the client
operate on a specific server side query/stored procedure including optionally resolving etc. However it usually doesnt
make sense to create lots of services each handling a single SQL resultset. Instead its better to group all those who
have something in common (eg. department level or functional level etc.) within one service and use the client side
named query syntax where you refer to a server side dataset definition without knowing anything about field, parameters,
database type etc. The required meta information will be automatically passed to the client when needed.
However a department level grouping would usually also require something more than just advanced dataset exchange, for
example some extra business code for calculation etc. which arent dataset oriented. This can _also_ be grouped into the
same service as the one handling the dataset operations and wont mess up the cleanness at all actually :) Thus you would
have one _complete_ service which contains all functionality for one departmental function for example.
This service can then be reused in all other application servers where needed without knowing anything about the actual
database setup, because that has also been abstracted out either via using the cross adapter components, or if the
database type is the same, but the setup different (different database) via the SessionName.
> > Hence its defined serverside, unless people
> > absolutely want to do it client side which kbmMW also supports. I can see
> however that I might want to create a couple
> > of pull down menus to make named query selection (by listing server side
> published named queries) easily available
> > during designtime. Noted.
>
> That's a good idea!
will try to have this into the next minor update.
> But I think you might be missing the point of how great a wizard the schema
> modeller is! <g> I'm sure Alessandro and Marc would be happy for you to
> continue to miss this point on this (! <g>) . . . but if you have a look
> through say the publicly available RO/DA DA01, DA02 and DA03 web articles
> I'm sure you'll get a sense of what this tool offers. I'm sure it must be
> 'kocher' for you to read each other's published documents, unless you have
> some gentleman's agreement otherwise. But maybe they log your address from
> your visits and rib you about it afterwards! <g>
Checking out the whitepapers, one thing I see that RO have and that could benefit kbmMW users is a couple of extra
designers to make a couple of things visually easier. For example grouping the kbmMW macro stuff for different database
types to make it visually easier to compare. This is what RO/DA calls dialects.
Technically however, kbmMW is fully capable of all the same as DA and then lots more.
> I'm not sure what you mean, but if you have a detailed look through the DA06
> article (strongly typed data tables), you will see that the starting point
> in the article is the schema 'customers' dataset. Based on the abstract
> interface ICustomers, on the server side then business processor classes
> (like kbmmw resolvers) are coded up to resolve the client deltas back to the
> server, and on the client side dataset-specific getters and setters are
> coded up / generated for the DataTable (functions roughly analogously to the
> kbmmwclientquery, except strongly typed). Business logic is defined by
> descending from ICustomers and adding business logic there, which can then
> be called from the client.
Agreed here is a difference. kbmMW doesnt have a similar feature as it has not until now been a milestone to create a
OPF as such. Lots of those exists, and in most cases people figure that the rowset type of operation is friendlier to
work with anyway than accessing records as strongly typed classes.
kbmMW has been built based on the ideas of ROI (return of interest) and CTD (cost to delivery). I have seen too many
frameworks in my time which, seen from a theoretical point of view were 'correct', but from a practical one a nightmare
to use. This is something I try to avoid happening with kbmMW :)
> So in this example from the RO/DA website, you can see that it starts with
> the abstract data definitions, which is done in a very visually RAD way
> using the schema modeller, but that this abstract definition also drives the
> coding of the server side resolving logic and of the client side getters and
> setters for the 'clientquery', and the definition of business logic related
> to the datset (in this case customers) which then sits on the server and can
> be called from the client.
The problem with strongly typed dataaccess is that it wont work very well in an everchanging world. When the fields
types for example change, its not able to adapt itself to the new world, or if fields are added/deleted that could cause
havoc if the client is not recompiled. Thus Im not too certain that this feature is really extremely useful outside a
theorectical view point. You may also have noticed some of the discussions in the oodesign NG when RemObjects published
their strongly typed dataset. It wasnt pure roses. Why? Not because it technically may be bad, but because its a hybrid
usually not solving any real world practical problems.
Im appreciating your input, and definitely willing to hear more!
-- best regards Kim Madsen kbm@components4developers.com www.components4developers.com The best components for the best developers kbmMW - kbmMemTable - kbmWABD - kbmX10
- Next message: C4D - Kim Madsen: "Re: Remobjects v KBM"
- Previous message: Kevin Powick: "Re: Good HD disk space use analyser?"
- In reply to: Lauchlan M: "Re: Remobjects v KBM"
- Next in thread: Lauchlan M: "Re: Remobjects v KBM"
- Reply: Lauchlan M: "Re: Remobjects v KBM"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
