Re: Design problem : security layers
Lew wrote:
You really only need one DB account for the whole DB layer, and the front end
would never access it.
subtenante wrote:
Reading your post again i could not really understand why you say
this. I have a "pool of pools" for my DB connections, i can't see why
i should have one account with all rights on all the tables, when i
can have several pools of accounts each of them dealing with its own
part of the db.
I say it because it's true. It's possible to develop an app that uses one DB
account, e.g., "myapp" for application "MyApp".
As to why you should or shouldn't do that, it depends. I usually use only a
single account because only the application I write uses the DB. Since users
don't need to access the DB, they don't need individual accounts. Fewer
accounts means less maintenance and lower Total Cost of Ownership (TCO) for my
customers, and higher control of security.
The application only deals with "its own part" of the DB. It has
authentication / authorization logic to determine what /its/ users are allowed
to do, but user access to the DB doesn't exist so those types of issues never
arise. Better control, lower TCO.
Easily said, but i guess you would have to browse all your classes to
make the appropriate changes in the request they do to the DB anyways.
I think it doesn't minimize the number of lines to change, only the
place where you store them.
Am i wrong ?
The truth is exactly the opposite. You don't "browse all your classes to make
the appropriate changes", you open the source for the one and only one class
that needs a change. The number of lines to change is approximately half of
the scheme that you propose.
I don't get it. Suppose you want to switch from a regular database to
an xml file, as Wojtek gave as example. You will still have to make
the changes for each type of operation for each type of object you
have. All these methods exist in any scheme, and would have to be
changed all the same, whichever class they are stored in.
But they will be in only one class, not two or an inheritance-tree-full. And
classes on the front end will not even see the change, much less be involved
in it. Lower maintenance effort, lower TCO.
Anyways i don't see why it makes half the lines to change. I still
think that's the same number of lines but all of them put in one
class, or split in packages depending on each concept.
I shouldn't have said "half", I should have said a moiety of lines compared to
duplicating the code in multiple layers.
Furthermore the lines will be together, not spread across multiple artifacts.
Less maintenance work, lower TCO.
Well, Wojtek himself admitted that his method was a lot of
maintaining, with a lot of duplicated code for similar objects. Could
you tell me how to avoid it ?
You can't avoid the work, but you can make it easier and pleasanter. Layered
architecture is a proven concept that has shown its value across gazillions of
projects.
sound and will accomplish the goals of isolation and security that you
espouse, with a sturdier and more compact architecture.
Inch'allah.
God helps those who help themselves.
--
Lew