DBX 4 Framework - Class Diagram - Delphi 2007 for Win32
Below the class diagram of DBX 4 Framework.
This model was build using Together Reverse Engineer in Delphi 2007 for Win32.
Is easy to understand the framework with this model.
Share This | Email this page to a friend
Posted by Andreano Lanusse on March 4th, 2007 under Delphi |12 Responses to “DBX 4 Framework - Class Diagram - Delphi 2007 for Win32”
Leave a Comment
Server Response from: dnrh2.codegear.com
March 4th, 2007 at 11:27 am
The layout is pretty tidy. Did you use the automated layout, or are the classes arranged by hand?
March 4th, 2007 at 11:32 am
I used automated layout.
Is much better than the first import :o)
March 5th, 2007 at 7:38 am
the very first time when i’ve seen dbexpress technology (d6?) i’ve been amazed about definition: dbx was meant to provide high performance, unidirectional, stateless datasets…
my perplexity came from:
1. borland always provided seamless design-time support for encapsulating business logic (datamodules for two tier and remote datamodules for 3+ tiers). inside these business logic "containers", people used client side "triggers" (e.g. Before/After-Delete/Cancel/Post/Edit to encapsulate their business logic in an elegant manner. this way, the separation between application kernels and presentation tiers was meant to be easy (RAD!) - now, because dbexpress cursors are stateless, this whole thing is literally lost (e.g. no Before/After-Delete/Cancel/Post/Edit) - this is my perplexity number 1!
2. since we are not doing paradox (local databases) anymore, a well designed application is supposed to access a very limited number of records at a time. the old days of opening a BDE TTable against 10,000,000 "customers" are over (btw, BDE used to handle that very well!). so, my point is simple: since the number of records we’re normally dealing with is very little, so is the performance gain from having stateless cursors… so, the gain is very little but the loss is very big (you loose all power described at pct 1) - this would be my second perplexity
These being said, maybe the borland architects and marketing folks will finally realize why almost everybody’s using 3rd party connectivity tools…
My 3rd perplexity is coming from the fact that despites all things described in here, borland/codegear/etc seams to still invest on technologies kinda of "divergent" from the delphi world…
I’d like to hear from you guys, not with fancy UML diagrams but with architectural solutions for the rest of us (the real world!) which will give us a reason to buy into your stories…
the first ones who should read this post are:
david_i, s_shougnessy, swindel and allen!
best regards,
frank borland
March 5th, 2007 at 9:33 am
*T*Int32?? Someone needs to be shot.
March 5th, 2007 at 11:04 am
don’t know anything about shots…
// dislike this idea!
but some basic Delphi training would definitely help (when your background is Java related…
but hey, it’s better than TBit, eh?:-) mean, it could have been worst…
keep up the great work guys!
fb
March 5th, 2007 at 9:58 pm
I didn’t mean to offend anyone with the TInt32, but I always know what that is. Just like I always know what an Int64 is. I thought this would also keep things more clear when we have 64 bit Delphi.
-Steve
March 6th, 2007 at 12:14 am
Hi Frank Borland,
I don’t agree with all of your claims, but I do share some of your concerns relating to applications built with BDE. We still have a significant number of developers that still use BDE.
First off, the dbExprsss 4 driver framework displayed above has no components. This is a driver framework that can be used directly by applications or indirectly through the dbExpress vcl components. It is more a kin to ADO.Net providers, BDP drivers and JDBC. There are a significant number of Delphi customers that use our drivers for DataSnap applications on win32 and ado.net applications on the .net platform.
I spent several years on the DOS Paradox team working in almost every area of the product including concurrency control, query optimization, data caching and access methods. I am familiar with its strengths and limitations. A key strength that you are touching on is support for a navigational data access model. Some people find this easier to work with. One of the reasons its easy to browse 10,000,000 rows is that it has no formal notion of a transaction. A consequence of this is that it also has no support for crash recovery.
On the other hand, most applications that work against transactional sql servers use a “set” oriented data access model. This is by far the most common data access model used for transactional sql servers. Jens Ole an I have developed both RAD based components and OR based solutions that support this model.
I like both the navigational and set oriented approaches. Navigational can be more simple and direct. The set approach is more generic and scalable.
In addition to the dbExpress 4 driver framework there is the preexisting dbExpress VCL. As you point out TSQLDataSet is unidirectional. These are designed to populate some form of “cached” TDataSet like the TClientDataSet. TSQLDataSet is not designed to support “Before/After-Delete/Cancel/Post/Edit” events, but TClientDataSet is. This is the set oriented approach. I think we must continue to support set oriented data access model for Delphi developers.
At this time I don’t have a public roadmap for what we will be doing after BDS2007, but I can share some of my perspective. Delphi has been around for over a decade and in that time has accrued several sets of data access components, tooling, and connectivity related technologies. We cannot afford to maintain and enhance all of these technologies. Some of these are outdated. Some never really took off. We need to decide where we will put our energy and where we won’t. Other wise we will go no where.
When I started last May we had over 16 database drivers for dbExpress and BDP. Customers do use these drivers. I am told by Michael Swindell that these drivers do help drive Delphi revenue. Believe me, if they didn’t, we would not build and maintain them. These drivers need to be continuously maintained and enhanced. With 64 bit support on the horizon the number of drivers doubles. Adding new drivers, supporting newer vendor client libraries, ADO.Net 2.0, Unicode support, streaming blobs, etc are all enough to bring us to our knees writing drivers. In addition all of the new connectivity features were developed in c# and only available to .net customers
So this year I decided to consolidate our dbExpress and BDP driver solutions. I’ll take the blame or credit for this. I still think it was the right call. This cuts our connectivity work load in half. In addition, this connectivity solution benefits both native and .net developers because the dbx driver framework and dbx vcl are both already single sourced.
Note that going forward we will continue our emphasis on providing single sourced feature sets written in Delphi and vcl based component solutions. This allows us to provide single implementation for Delphi/c++ native and .net manage platforms.
Working on connectivity has been very time consuming. However, when the .net release ships you will see that we have been working on more than just connectivity.
With the simplification of our connectivity offerings we will have more breathing room to address some other high priority issues like data access components, datasnap, migrating older applications to newer data access models, and improved tooling.
-Steve
March 6th, 2007 at 12:35 pm
"I didn’t mean to offend anyone with the TInt32, but I always know what that is. Just like I always know what an Int64 is. I thought this would also keep things more clear when we have 64 bit Delphi."
That wasn’t my point, I welcome the Int* types and the previous post was in jest. What I question is attaching the T to a primitive type name. That makes as much sense as would renaming Int64 to TInt64, or Integer to TInteger. Some consistency would be appreciated.
March 7th, 2007 at 11:20 am
Steve,
I would not answer your very long email, despites I’d like to, but… Well, the fact that you answered me, clearly shows that "smart people like to work with smart people" (we have this saying in here… where i am) — this should normally trigger a lot of historical question-marks… (e.g. why oh my wasn’t this possible in the past…)
I do own you one simple answer:
VCL connectivity architecture (BDE, ADO, 3rd parties) has a very unique feature, the one of providing design-time support for "business-rules layer encapsulation". This is based on datasets (as in TCustomDataSet descendents) with STATE. DBExpress simply cloned a micr*s*ft feature (mostly because the architect and marketing didn’t know any better, by that time, in very early 2000s…) without fully understanding all side effects… I am not talking about more components to get the very same job done (e.g from BDE’s TTable->TDataSource->dbAware(s) to TSQLTable->TDataProvider->TClientDataSet, etc). Even if you do composition, to reduce the number of components to the old days of bare bones BDE, there is something left… and that something is subtle/important! read further:
TClientDataSet has state. The fact that you have to ApplyUpdates is not a big deal. The problem comes when you implement the business -rules logic using TClientDataSets and here is why:
the relationship between TDataProvider & TClientDataset seams to be very simple, however, it’s not! Midas.DLL (the mediator) doesn’t seam to do more than marshaling back and forth compressed deltas (mostly compressed transaction logs) at high pace rate! This kills the CPU and renders the classical "business-rules" in client modules or even remote data-modules irrelevant. All the advantages of using read-only / unidirectional datasets are actually vanished by and because of Midas.DLL and the way the whole thing was initially designed (when Borland purchased it, right?)
This IS the true reason for people to still be using 3rd party client connectivity components… There is one more thing to add to this one. I’m gonna use Anders’s Words in calling BDE, ADO, etc by "suffering from the less common denominator" - meaning, more generic you go, less specific you can be. I am talking about Anders Hejlsberg here! Yet another guy with "not enough abstraction power" - right?
lol - btw, he’s doing very well!
Anyway, keep up the good work, I wish we were together in this jurney… it was not to be Steve…
Good Luck,
fb
March 7th, 2007 at 11:38 am
well, if you spent so many years in paradox, you must know that when you open a BDE TTable against a 100,000,000 records/rows .db, only a few records are actually retrieved (depending on what dbaware controls are actually hooked to the datasource, bde settings for the sliding buffer, etc). it’s not some people finding this attractive, but rather all people…
also, you must know that the transaction commit only flushes the transaction log which is a O(n) of transaction log size…
so, executive summary:
1. all people loved the way TTable worked/works. this offered a O(1) scalability to development teams
2. TTable model was perfectly aware of transactions
3. Transactions are O(n) of transaction log size and not of record-count…
Just my $.2
fb
your text follows:
*** I spent several years on the DOS Paradox team working in almost every area of the product including concurrency control, query optimization, data caching and access methods. I am familiar with its strengths and limitations. A key strength that you are touching on is support for a navigational data access model. Some people find this easier to work with. One of the reasons its easy to browse 10,000,000 rows is that it has no formal notion of a transaction. A consequence of this is that it also has no support for crash recovery.
March 9th, 2007 at 7:44 pm
Hi Frank Borland,
There are many applications where the navigational data access model of Paradox works great and is easy to work with.
Most of the world’s data is in a transactional database for good reasons. I know they are not as easy to work with as Paradox. However, Paradox cannot provide the ACID properties of a transactional database and it cannot come close to scaling to the thousands of concurrent users that a transactional database can handle.
Which you choose depends on your application. They are both relevant.
The bottom line is that I hear you and I do think you are making some good points. You like the Paradox model and you are not alone. I realize we have a lot of existing customers using Paradox and dBASE. I needed to sort through a lot of connectivity issues this release. The next cycle I plan to put more attention on TDataSet related components.
-Steve
March 14th, 2007 at 3:48 pm
I read this conversation with interest, because of the similarities with the software at our shop;
We work with hundreds of tables containing millions of records each, some are 8+ GB in size, total database size has exceeded 100 GB at one customer.
We access them sequentially at first, but need high-performant random access after that. During this fase, no editing is done anymore. (This usage-pattern is very common in data-mining tools too.)
We’ve profiled lots of drivers, to see which fits this usage-pattern best. Our final conclusion was that our own in-house TDataSet-clone performed best (it’s build around the MemoryMappedFile API, in combination with an efficient, heuristical sliding window mechanism).
It has cost us a lot to get to the point we are now, just because Paradox (or any other driver) did not offer us the throughput we knew was possible. Also, not everybody needs transactions, rollbacks, and all the other fancy stuff.
My point is : Don’t focus solely on set-based drivers! I believe there are enough applications that need high-volume, high-performing random-access database-access, so don’t let us standing in the cold!
(Just my 5 cents.)