 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Corinna
Guest
|
 Posted: Tue Sep 12, 2006 1:26 am Post subject: use of table views |
 |
|
I'm musing on an idea that is still half-formed, and I was hoping that
someone here could point me in the right direction. My idea is to
"encapsulate" a table and only use views on it to allow the user to be
able to manipulate a subset of the records in my program. But I'm not
sure how to implement this.
Our code is still very coupled, etc, so there's no framework or any
other kind of OO design, really. (The problem with this kind of code is
that it's hard to determine where to being fixing things - like cleaning
your kid's room!)
The shape of my idea is to create several views (active clients,
inactive clients, clients within 2 mile radius, etc). The program will
have options to filter the table in one of these ways, and all reports,
etc will automatically know to act on this subset of data. I'm thinking
the way to go about this is to have a data module which contains a table
component whose name reflects whichever view is in effect. Then all
areas of the program simply reference this one component, thus
automatically getting the data in the current view, and not having to
know any details about which view is in effect.
The one kink that I can think of, is that this makes it impossible to do
queries, and forces me to rely on filters, Locate, etc, which I don't
want to do.
As I said, my ideas are still very vague, and I haven't worked with
views in any practical way before, and my architecture skills are very
primitive, too, so any guidance would be appreciated, even if it's just
a link to someplace that explains the basic use of views!
-Corinna |
|
| Back to top |
|
 |
Charles McAllister
Guest
|
| Posted: Tue Sep 12, 2006 3:03 am Post subject: Re: use of table views |
|
|
Corinna wrote:
| Quote: | I'm musing on an idea that is still half-formed, and I was hoping that
someone here could point me in the right direction. My idea is to
"encapsulate" a table and only use views on it to allow the user to be
able to manipulate a subset of the records in my program. But I'm not
sure how to implement this.
if you're certain that you want to keep using TDataSets as the basis for your framework, then i'd suggest taking a look at instantobjects (http://www.instantobjects.org/), as that appears to be their approach. HTH. |
|
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Tue Sep 12, 2006 3:07 am Post subject: Re: use of table views |
|
|
Corinna wrote:
| Quote: | My idea is to
"encapsulate" a table and only use views on it to allow the user to be
able to manipulate a subset of the records in my program. But I'm not
sure how to implement this.
The shape of my idea is to create several views (active clients,
inactive clients, clients within 2 mile radius, etc). The program will
have options to filter the table in one of these ways, and all
reports, etc will automatically know to act on this subset of data.
|
I would recommend against this idea in general. There's nothing wrong with
using database-side views, but I would use them to:
1) simplify commonly needed complex queries
2) provide security
But I would not use them to otherwise proscribe or limit the freedom of an
application to query the database. Doing so means you will almost constantly
find you need to add "just one more" view, and for every new or changed view
you will also need to change the corresponding code in the application. For
example, you'll find you need to see active and inactive clients together,
or there'll be a case where you need to allow a 3 or 5 mile radius. These
are things the *application* should be allowed to decide.
In the case of active/inactive, it may be valid to use a view that only
returns inactive clients if user has a certain security permission.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"At the apex of every great tragedy of mankind there stands the figure
of an incorruptible altruist." - Ayn Rand |
|
| Back to top |
|
|
Joao Morais
Guest
|
| Posted: Tue Sep 12, 2006 3:25 pm Post subject: Re: use of table views |
|
|
Charles McAllister wrote:
| Quote: | I'm musing on an idea that is still half-formed, and I was hoping that
someone here could point me in the right direction. My idea is to
"encapsulate" a table and only use views on it to allow the user to be
able to manipulate a subset of the records in my program. But I'm not
sure how to implement this.
if you're certain that you want to keep using TDataSets as the basis for
your framework, then i'd suggest taking a look at instantobjects
(http://www.instantobjects.org/), as that appears to be their approach.
|
The default InstantObjects *presentation* uses TDataSet decendants, but
you can write your own presentation for IO objects. By the way, I'm
writing an application framework that implements MVP and uses IO to
persist my BOs (for the time being).
--
Joao Morais |
|
| Back to top |
|
|
Corinna
Guest
|
| Posted: Wed Sep 13, 2006 6:12 pm Post subject: Re: use of table views |
|
|
You make some good points...
Wayne Niddery [TeamB] wrote:
| Quote: | But I would not use them to otherwise proscribe or limit the freedom of an
application to query the database. Doing so means you will almost constantly
find you need to add "just one more" view, and for every new or changed view
you will also need to change the corresponding code in the application. For
example, you'll find you need to see active and inactive clients together,
or there'll be a case where you need to allow a 3 or 5 mile radius. These
are things the *application* should be allowed to decide.
|
The situation is that the application currently doesn't have any kind of
filtering, and our customers have asked for that kind of filtering for
reports, display lists, and so forth. I'm thinking the easiest way to
implement this feature would be to use views, because it seems to me
that the alternative is to re-do all the report dialogs to include
options for active, inactive, etc (we don't use inheritance, and GUI is
tightly coupled to implmentation... yeah, I know, don't say it...). This
would take a lot of time and require a lot of testing.
I suppose I could have some global state variable that is checked when
constructing a report query (adding a clause to WHERE), or setting a
table filter (for grids, etc).
A side issue I guess, is if there's some way to use a query to, say,
select clients within a certain radius, and then have other queries
select from that dataset (a query of a query)? Maybe using clientDataSets?
I want to be able to implement a global filter on the data without
rewriting (or modifying/refactoring/redesigning) a bunch of code. But I
also want to do it intelligently (so future programmers can deal with it
and not curse my name  ). I also want my solution to fit as I
gradually fix the design issues in the code base.
For what it's worth, one of my ongoing projects is to clean up our
database usage (improve queries, normalize tables, decouple code, etc).
And from reading here, I understand the importance of good design, so I
don't want anyone to think I'm just being lazy :)
-Corinna |
|
| Back to top |
|
|
Corinna
Guest
|
| Posted: Wed Sep 13, 2006 6:31 pm Post subject: Re: use of table views |
|
|
Charles McAllister wrote:
| Quote: | if you're certain that you want to keep using TDataSets as the basis for
your framework,
|
Well, I don't exactly have a framework... There's far too much that
needs improvement, design-wise, to even be thinking about frameworks
yet. I don't think I'm going to be on the project long enough to that
kind of surgery... My minimal goal is to reduce the rampant coupling of
units, and reduce the amount of data being transmitted across the
network. There's not much I can do about the use of TDataset and
data-aware controls, and code mixed in with the UI, and so forth. There
are more serious smells to deal with for now.
The best I can do as I implement new features is to try to be
intelligent about it so I don't interfere with future code improvements.
I was thinking that using views might be a good way to do the global
filtering, but maybe there's no good solution at this point that doesn't
involve touching a lot of units.
-Corinna |
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Wed Sep 13, 2006 8:23 pm Post subject: Re: use of table views |
|
|
Corinna wrote:
| Quote: |
The best I can do as I implement new features is to try to be
intelligent about it so I don't interfere with future code
improvements. I was thinking that using views might be a good way to
do the global filtering, but maybe there's no good solution at this
point that doesn't involve touching a lot of units.
|
Double-edged sword - they may be the most expedient solution, but as far as
future programmers cursing your name, you'll definitely be asking for it
this way. <g>
In such an application you are right that you need to limit yourself to
those things that get the the biggest bang for the buck, you can't fix
everything in a short time.
As long as the application is generally using SQL at least, it shouldn't be
too bad a job to add where clauses to them based on criteria selected by the
user. Depending on how horrific the current code is, you might have to
carefully trace where a particular dataset is used (e.g. if it's in a
datamodule and used by multiple forms). If necessary, add another dataset in
order to isolate use so you are free to mess with its SQL without affecting
other parts dependent on the current dataset.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Reality is that which, when you stop believing in it, doesn't go
away." - Philip K. Dick |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
