Design problem : security layers

[subtenante]

Hi,

I'm fresh in java (started learning in december, by myself because
already in "enterprise scope"), and i'm having a little trouble.

I have to make a website, in jsp, and currently working on the
business model.

I'd like to reuse the Objects i write for the frontend in the backend,
namely the ones in the frontend generally have only getters, and the
ones in the backend also have setters.

So for the moment what i do is having two packages, namely frontend
and backend, and the backend Objects all extend from the frontend
ones.

Except that the frontend ones depend on each other : for example an
article will have an author Object in its attributes. But Author in
frontend has only getters.
When i do the backend version, it seems that if i directly extend from
the frontend class Article, the Author object used will be the one
from the frontend package also.

The only solution for the moment that i see is to create the Author
class as default (non public - non private), and write all the getters
setters for it. In the frontend I also write all the setters for the
Author in the Article class.

Then, when i go to the backend, i can extend and add the setters for
the Author, which are available.

But i'm not sure of this design. Anybody have suggestions on this kind
of problem ? A name of pattern to throw me i could dive into ?

Thanks.

 

[subtenante]

The only solution for the moment that i see is to create the Author
class as default (non public - non private), and write all the getters
setters for it. In the frontend I also write all the *Getters* for the
Author in the Article class.

 

[Lew]

But i'm not sure of this design. Anybody have suggestions on this kind
of problem ? A name of pattern to throw me i could dive into ?

"Front Controller", a.k.a. "Model-View-Controller" (MVC).

JSF and Struts implement it.

You should have only one entity class, not a hierarchy, for each entity type.

 

[Wojtek]

subtenante wrote :

Hi,

So for the moment what i do is having two packages, namely frontend
and backend, and the backend Objects all extend from the frontend
ones.

I usually split my packages by use case. So each package holds all the
classes required for one function. This includes the servlet, business
rules code and the Data class. The data class consists of only
attributes and their respective getter/setter pairs.

The Data class holds all the information which the JSP needs. The
information is loaded by the SQL class, inspected by the business class
(including setting flags). The Data object is then placed into the
HttpRequest.

The JSP picks out the Data object from the request and displays the
information held within it. It may also highlight some information
depending on the flags.

With each use case in its own package, and minimal interaction between
packages (except for the framework), I greatly reduce the probability
that a change in one package will affect another package.

 

[Ed]

I usually split my packages by use case. So each package holds all the
classes required for one function. This includes the servlet, business
rules code and the Data class. The data class consists of only
attributes and their respective getter/setter pairs.



With each use case in its own package, and minimal interaction between
packages (except for the framework), I greatly reduce the probability
that a change in one package will affect another package.

An interesting approach. I've often wondered how a package-per-feature
would look; your package-per-use-case looks even more advanced in that
direction.

Wojtek, can you tell me how you handle re-use between use cases?

..ed

 

[Ed]

Hi,

I'm fresh in java (started learning in december, by myself because
already in "enterprise scope"), and i'm having a little trouble.

I have to make a website, in jsp, and currently working on the
business model.

I'd like to reuse the Objects i write for the frontend in the backend,
namely the ones in the frontend generally have only getters, and the
ones in the backend also have setters.

So for the moment what i do is having two packages, namely frontend
and backend, and the backend Objects all extend from the frontend
ones.

Subtenante, I've read your post a couple of times, and I'm afraid I
don't understand. So this post is really a request for more
information.

Firstly: what do the words, "Frontend," and, "Backend," mean to you?
I've a feeling that they are well-defined terms in your field, but I'm
unfamiliar with them. (I don't know JSP, so maybe they're well-known
JSP terms, in which case you can stop reading here as all my advice
will be irrelevant.)

Secondly, I presume the system you're working on is not gigantic:
there are no fixed rules for the number of classes per package, but 50
is generally an upper limit. I presume you're not dealing here with
more than 100 classes in these two packages.

Except that the frontend ones depend on each other : for example an
article will have an author Object in its attributes. But Author in
frontend has only getters.

An article has an author: what is it that you're designing? A
reference library of some sort?

I truly do not understand why a frontend (whatever that is) should
only have getters and a backend should only have setters.

When i do the backend version, it seems that if i directly extend from
the frontend class Article, the Author object used will be the one
from the frontend package also.

Re-use is great, of course. You want to maximise your functionality
per line of code. But I don't understand how inheriting from one
package to another automatically brings this benefit.

If one class in backend inherits from a class in frontend, and then
that backend class is instantiated, there is only one object
instantiated: there are not two objects created, one in the backend
and one in the frontend. You can consider the instantiated object as a
mash of the backend object and the frontend object: but it's just one
object, not two.

The only solution for the moment that i see is to create the Author
class as default (non public - non private), and write all the getters
setters for it. In the frontend I also write all the setters for the
Author in the Article class.

I don't understand this: perhaps you could supply more information, or
details of the specific classes?

But if I were you, and this is just a project to get you used to Java,
then I'd forget about re-use. Re-use opportunities will present
themselves unmistakably (you'll be writing the same methods in
different places) and when they present themselves, deal with them
then.

I'd be far, far more interested in designing a solution to the problem
you're trying to solve as simply as possible, but with the flexibility
to change it to any ideas for the future that you might have.

Also, just as classes are encapsulated behaviour, think of packages as
encapsulated behaviour of a rougher granularity. If you have a
reference library application (as guessed) then you'll probably have
the following funtionality:
- Create a library.
- Add a work (with author, and perhaps cross-reference to other
works).
- Delete a work.
- Search for a work (or all works by an author, or any other
attribute).
- Save library.

These are all rough-grained behaviours. And though I wouldn't put each
in its own package (as Wojtek does - and feel free to chose his
approach), I'd imagine that you'd have the following packages
(presuming you're using Model-View-Controller, which you're maybe not
using, but it's a good way to separate the core functionality from the
way this is presented to the user, and you did say that you're working
on the, "Business model," which would be the model here):
com.subtenante.controller - parses commands from user and kicks off
execution in the model.
com.subtenante.model - holding package for main functionality.
com.subtenante.model.library - holds main functionality for the
library
com.subtenante.view - holding package for the presentation of your
library
com.subtenante.view.gui - GUI specifics for your library (if any).
com.subtenante.view.console - text specifics for your library.

Of coures, using JSP limits your view (you almost certainly won't have
a console view) but it demonstrates how packages should hold related
behaviours.

This also reinforces my lack of comprehension of your frontend and
backend.

And that com.subtenante.model.library will be further sub-packaged
depending on the application you're designing. It could be guessed
further that a major part of your library could be the search you use
to interrogate the library, and so maybe the library would have a
further sub-package:
com.subtenante.model.library.search

This is especially true if you could consider using a totally
different search engine in future.

Also, perhaps the indexing you use is a substantial piece of behaviour
that could be replaced by a different system of indexiing in future;
in this case you'd probably also have:
com.subtenante.model.library.index

If you could also envisage some sort of authentication whereby only
certain users could view the works of certain authors (ok, maybe a bit
Nazi, but you get the point) then you might want to allow you users to
log-on and base authentication on them, in which case you might have a
slew of sub-packages, beginning with:
com.subtenante.model.library.user
com.subtenante.model.library.security

And what if you want to charge people for use of your libary? Well,
then have:
com.subtenante.model.user.credit
com.subtenante.model.user.restrict
com.subtenante.model.user.history

Again, the credit sub-package will contain all that behaviour that
checks the user's back-account to ensure that he has enough money to
view the work he seeks. The history sub-package will hold the
functionality to show all the works the user has ever viewed.

These are, of course, just guesses, but the intent is to show that the
two packages frontend and backend don't really describe what those
packages do (outside those expert circles that understand those
terms).

Another way to look at it is this: if you have a requirement to change
something in your system in a few months time, will the person
implementing the change have a good idea where to look just based on
the package names?

Using MVC (sort of) as described above, the programmer will know that
a change to the GUI will not affect the com.subtenante.model sub-
packages so much.

Whether a GUI change will impact frontend or backend more, I have no
idea.

Then, when i go to the backend, i can extend and add the setters for
the Author, which are available.

But i'm not sure of this design. Anybody have suggestions on this kind
of problem ? A name of pattern to throw me i could dive into ?

Thanks.

..ed

 

[Wojtek]

Ed wrote :

An interesting approach. I've often wondered how a package-per-feature
would look; your package-per-use-case looks even more advanced in that
direction.

Wojtek, can you tell me how you handle re-use between use cases?

package names:

person
person.common
person.edit
person.filter
person.list

So the common package holds classes which are used by filter, list,
and/or edit, yet all are contained within person. These are usually
data holders.

In the case where a class might be used all over the place, that whole
"concept" gets its own package, usually in the framework.

Where the same code might be used between similar concepts such as
person.list and apes.list I used redundant code.

I spent quite a bit of time working out patterns which my use cases
use, so the same code flow is used in both person.list and apes.list,
with only imports and variable names being different.

If I need to make a pattern change (really rare now), then I go through
all the code, so that all the same patterns really are the same.

Maintaining the pattern IS a lot of work, but once set, it makes
creating new use cases a snap. Create a package set, copy, paste,
rename some classes, rename some variables, and there you go, a working
robust list and edit.

Also, I use the minimal posssible scope for everything. So the
classes/methods in a use case usually have package level scope, that is
there is no public modifier.

 

[subtenante]

Wow, thanks a lot Ed, for the time you spent answering.

I'll give you a bit more information here.

Firstly: what do the words, "Frontend," and, "Backend," mean to you?

The usual in the website paradigm : frontend is the website viewed by
users, backend the one seen by administrators.

My concern is security. I perhaps should have said that before.
I need the normal users of the website to have limited rights on the
objects they use (most of them don't even know they are creating
objects on my server, but you see my meaning).
That's the reason for the frontend package. The objects in that one
have very limited rights : only getters (and not all of them). This
way i am sure that the frontend webpages, which only import the
frontend package, have limited rights.

On the other end, i need the administrators to work on the objects in
the database, so create and update them. Therefore i need setters, and
a DB interface. I wondered if i would have two different classes for
each object or not, in the beginning i decided to extend the backend
ones from the frontend ones. But i'm reconsidering this.

Secondly, I presume the system you're working on is not gigantic:
there are no fixed rules for the number of classes per package, but 50
is generally an upper limit. I presume you're not dealing here with
more than 100 classes in these two packages.
Right.

An article has an author: what is it that you're designing? A
reference library of some sort?

It's only an example. Although i also have this articles/authors
structure in my model, it's not the main part.

I truly do not understand why a frontend (whatever that is) should
only have getters and a backend should only have setters.

Backend needs both, that why i extend in backend from frontend.

It's not likely that i am to maintain this project a long time, that's
why i wanted to be kind to the maintainers and have the least
redundant code possible.

If one class in backend inherits from a class in frontend, and then
that backend class is instantiated, there is only one object
instantiated: there are not two objects created, one in the backend
and one in the frontend. You can consider the instantiated object as a
mash of the backend object and the frontend object: but it's just one
object, not two.

I know. Backend users have their own objects, frontend users will
create theirs by themselves when they connect to the frontend of the
website.

But if I were you, and this is just a project to get you used to Java,
then I'd forget about re-use. Re-use opportunities will present
themselves unmistakably (you'll be writing the same methods in
different places) and when they present themselves, deal with them
then.

Well that's the point. What i don't like about java is the "only one
inheritance", my problem would be solved otherwise.

If i do not inherit from the backend to their frontend version, i have
to recode all the constructors (sometimes heavy ones), and every
change in one attribute has to be done twice. I'm personnally not much
worried about it but i might not be the maintainer (and i work in an
"emerging" country : they have good programmers but poor english and
therefore limited access to documentation).

And because there is not multiple inheritance, i have to embed some
objects in my frontend ones. An author is an attribute of an article.
But they both are the frontend version (light getters). When i inherit
in the backend Article, i still have a frontend Author in it. But i
don't want it : i want a backend Author !

I was thinking that maybe generics would do the trick, but i'm not
sure how to make it work right now, and it makes every definition of
my objects a lot heavier (call
Article<backend.Author,backend.Language,backend.Comments,...>).
I guess i could make another screening class that would create these
objects directly. Have to think about this.

These are all rough-grained behaviours. And though I wouldn't put each
in its own package (as Wojtek does - and feel free to chose his
approach), I'd imagine that you'd have the following packages
(presuming you're using Model-View-Controller, which you're maybe not
using, but it's a good way to separate the core functionality from the
way this is presented to the user

I thought that my db/jsp/java was already a MVC approach... You're
telling me there can be different MVC at different scales, that is one
db/jsp/java and one more within the java code ?

Anyways, thanks again for you long answer and all the details.
sub.

 

[subtenante]

"Front Controller", a.k.a. "Model-View-Controller" (MVC).

JSF and Struts implement it.

You should have only one entity class, not a hierarchy, for each entity type.

Thanks Lew.

I have short time, and learning JSF or Struts would have taken too
much time (i seriously considered them and made a first attempt to use
them, but the "return on time investment" would not have been good
enough...).

 

[subtenante]

subtenante wrote :

I usually split my packages by use case. So each package holds all the
classes required for one function. This includes the servlet, business
rules code and the Data class. The data class consists of only
attributes and their respective getter/setter pairs.

Yep, i see your point, and it's mine too !
I'm not that much splitting the packages,but the backend/frontend
separation has the same philosophy i think. (In case i need only to
watch the website, there is the frontend package, in case i need also
to change the data i have the backend one. But in both cases the
objects have a lot of similarities.)

The Data class holds all the information which the JSP needs. The
information is loaded by the SQL class, inspected by the business class
(including setting flags). The Data object is then placed into the
HttpRequest.

The thing is that i look at my website as two separate ones. The
backend interferes with the database, updating it. The frontend only
reads it. They use the same kinds of objects, but never interact
directly, they always interact through the DB.

With each use case in its own package, and minimal interaction between
packages (except for the framework), I greatly reduce the probability
that a change in one package will affect another package.

Well i *want* (and need) that a change in a frontend object makes a
change on the backend one. I want them both to have almost the same
attributes, generally, and i want for example all the getters (or
displaying methods) to be the same in the backend than in the frontend
(and not to have to do the changes twice every time). But i really do
not want the frontend objects to be able to make any change in the
database.

 

[Wojtek]

subtenante wrote :

The thing is that i look at my website as two separate ones. The
backend interferes with the database, updating it. The frontend only
reads it. They use the same kinds of objects, but never interact
directly, they always interact through the DB.

Your JSP pages access the database? Or even know about it?

In my scenario, the front end only gets information from a Data object.
So the JSP only knows about the Data object. How that information got
put into the Data object it totally irrelevant to the JSP.

The way I have layered the classes, I can switch database technologies
by simply re-writing ONE set of classes in the "backend", and setting a
configuration file. Whether that new database is a different database,
an XML file, a flat file, or whatever, it is completely hidden from the
JSP.

A given database class knows how to access its database, the proper
syntax for that database (including any quirks), and has all the
methods for the normal CRUDL.

Well i *want* (and need) that a change in a frontend object makes a
change on the backend one. I want them both to have almost the same
attributes, generally, and i want for example all the getters (or
displaying methods) to be the same in the backend than in the frontend
(and not to have to do the changes twice every time).

The normal round trip is that the user fills in some information, then
clicks on a submit button.

A servlet starts up. It reaches into the request and picks out the page
fields. Depending on the button, the servlet performs some sort of
action.

In my setup, the servlet populates the Data object with the user's
entered information. If the action is "Update", then the Data object is
validated. If the validation succeeds, then the Data abject is passed
to the database class, and the servlet re-directs to another servlet.

If the validation fails, then the Data object is placed into the
request, and the JSP is called. The JSP displays the information in the
Data object (which in this case is the bad information). The JSP also
displays any error messages.

If this is the first time to that servlet, then it calls the database
class to get the information from the database. The database method
creates the Data object, fills it with values from the database, and
passes it back to the servlet, which calls the JSP.

So the JSP only needs to know about ONE object, the Data object.

But i really do
not want the frontend objects to be able to make any change in the
database.

With only ONE Data object which is passed around, then you only need to
change that one class. Since it has both getters and setters for a
given attribute, then any change (almost) automatically is seen by both
users of the object.

In your case, any new attribute must be put into two objects.

Also, since I am using minimal scope, the JSP cannot even get at the
classes which "play" with the database.

 

[subtenante]

Your JSP pages access the database? Or even know about it?

Well no, i thought it was obvious. The database interface is done in a
separate package.

In my scenario, the front end only gets information from a Data object.
So the JSP only knows about the Data object. How that information got
put into the Data object it totally irrelevant to the JSP.

That's my point. I want the jsp from the frontend to use the frontend
package, containing only lightweight versions of the objects. This
way, i am sure it is impossible to update anything not permitted from
the jsp. Only a very few setters are available, and not even all of
the getters.

But in the backend of the website, i need the jsp's to use the backend
package, containing the objects, inheriting from the frontend ones,
and having the additional features to make changes to the DB.

This way i am sure that when a new feature is added to a jsp page, it
can not be problematic for security : from the design level it is not
permitted to add features to update not permitted information.

By the way, the frontend package uses a very limited DB account, only
granted with "execute". For the backend I have a lot of DB accounts,
each with the necessary rights and no more.

(Now you are going to think i am paranoid.)
(Ok, spit it, i don't care.)
(You know, paranoids also have enemies.)
(Are you one of them ? Hmm ?)

The way I have layered the classes, I can switch database technologies
by simply re-writing ONE set of classes in the "backend", and setting a
configuration file. Whether that new database is a different database,
an XML file, a flat file, or whatever, it is completely hidden from the
JSP.

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 normal round trip is that the user fills in some information, then
clicks on a submit button.
...
So the JSP only needs to know about ONE object, the Data object.

Yes but i have two sets of jsp's. One in the frontend, that must use
limited versions of the Objects (therefore i give no way to put a mess
in my data this way, everything is strictly controlled). One in the
backend, where i am slightly more relax (slightly).

With only ONE Data object which is passed around, then you only need to
change that one class. Since it has both getters and setters for a
given attribute, then any change (almost) automatically is seen by both
users of the object.

Yes but i don't trust the next developpers/maintainers. I have seen
ugly things, precisely that's the reason i am doing everything from
scratch. I want a design that makes completely sure that the people
that will care about this later will understand which data is
sensitive and which is not, so that they don't do ugly things.

In your case, any new attribute must be put into two objects.

Not if i inherit. Which i'm trying to do, and it seems it's not that
bad.

Let's take

class Article1{
protected Author1 author;
....
}

and

class Article2 extends Article1{
protected Author2 author;
....
}

Provided that i have defined Author1 and Author2 each in its
appropriate package (namely frontend and backend), and Author2 also
extends from Author1.

It seems that in Article2, i no longer have any reference to the
Author1 from the Article1, it is completely replaced by a Author2. So
i'll try to see but the methods from Article1 are still available, and
might work on Author2 as if it were a Author1. Which is fine, because
for the sensible operations, i define everything in Article2.

Don't know if you get my meaning.
I think i get it, so i may be able to explain better.

Also, since I am using minimal scope, the JSP cannot even get at the
classes which "play" with the database.

But let's say you have two classes : Article and Author.
You want 6 methods : select, insert and update for each of these
classes.
As far as i understand you have one big package database which makes
the closest part to the database available (pooling connections,
etc.). You also have two packages :
article.db
author.db
in which you have classes where methods can be found to make the
operations.
But how is it inside these packages ? One class per operation ?
Select.java
Insert.java
Update.java
or one big class for everything ?

Anyways, thanks for your time.

 

[Wojtek]

subtenante wrote :

Well no, i thought it was obvious. The database interface is done in a
separate package.

Yes. But does your JSP use database aware classes? That is what i
meant.

That's my point. I want the jsp from the frontend to use the frontend
package, containing only lightweight versions of the objects. This
way, i am sure it is impossible to update anything not permitted from
the jsp. Only a very few setters are available, and not even all of
the getters.

So what you need to do is make your database access classes final, and
limit their scope to the package. So rather than having:

-------------------
public final class Foo()
{
}
-------------------

You have

-------------------
final class Foo()
{
}
-------------------

That way Foo cannot be extended, and it is not visible outside the
package.

(Now you are going to think i am paranoid.)
(Ok, spit it, i don't care.)
(You know, paranoids also have enemies.)
(Are you one of them ? Hmm ?)

Yes, I am one of them

 

[Lew]

Well no, i thought it was obvious. The database interface is done in a
separate package.

So your JSPs do not use the database classes.

(BTW, JSPs aren't usually thought of as being in a package.)

That's my point. I want the jsp from the frontend to use the frontend
package, containing only lightweight versions of the objects. This
way, i am sure it is impossible to update anything not permitted from
the jsp. Only a very few setters are available, and not even all of
the getters.

You enforce security by how you access an object, not by needless duplication
of the object.

But in the backend of the website, i need the jsp's to use the backend
package, containing the objects, inheriting from the frontend ones,
and having the additional features to make changes to the DB.

JSPs are a strictly front-end artifact. JSPs "in the backend [sic]" are a
contradiction in terms. JSPs are for visual presentation (or the equivalent),
the very definition of "front end".

This way i am sure that when a new feature is added to a jsp page, it
can not be problematic for security : from the design level it is not
permitted to add features to update not permitted information.

This is better done without duplicating your classes.

By the way, the frontend package uses a very limited DB account, only
granted with "execute". For the backend I have a lot of DB accounts,
each with the necessary rights and no more.

You really only need one DB account for the whole DB layer, and the front end
would never access it.

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 ?

Yes, you are.

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.

Yes but i have two sets of jsp's. One in the frontend, that must use
limited versions of the Objects (therefore i give no way to put a mess
in my data this way, everything is strictly controlled). One in the
backend, where i am slightly more relax (slightly).

JSPs are front-end artifacts. Only.

What do you mean by a "set of jsp's [sic] ... in the backend [sic]"?

The phrase makes no sense to me whatsoever. Why would you want HTML in the
back end, where no one can see it?

Yes but i don't trust the next developpers/maintainers. I have seen
ugly things, precisely that's the reason i am doing everything from
scratch. I want a design that makes completely sure that the people
that will care about this later will understand which data is
sensitive and which is not, so that they don't do ugly things.

This can be accomplished without making maintainers' jobs more difficult, too.

I strongly recommend that you study Wojtek's suggestions in depth. They are
sound and will accomplish the goals of isolation and security that you
espouse, with a sturdier and more compact architecture.

 

[subtenante]

Thanks for your answers Lew. No need though to talk to me as if i were
stupid (maybe i am, but that's not quite polite, and not the best way
to make me understand my mistakes). If you don't understand my
questions, it's because we don't talk about the same thing. When i say
backend, i mean backend of a website. The place where administrators
connect via a http/html interface to update the information of the
website. Everybody i know working on websites calls this a backend
(implicitly : of the website).

My security concern is not only about the users, it's also about the
maintainers. Who often do nonsensical things here. I have special
requirements. And i'm being listening to the answers of Wojtek, and
asking him questions. Now if my language seems strange to you, maybe
it's also because i'm not a native english speaker, and i'm doing my
best.

 

[subtenante]

Yes. But does your JSP use database aware classes? That is what i
meant.

They did. They won't.

That way Foo cannot be extended, and it is not visible outside the
package.

Ok.
I'm still worried about maintainance but i guess you've got nothing
for free.

Yes, I am one of them

Whether you are or not (they all are anyways !) you seriously helped
me.
I'm not sure i'll do things right this way from the beginning but i
guess i'll learn by doing it.
Thanks for your time.

 

[subtenante]

You really only need one DB account for the whole DB layer, and the front end
would never access it.

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.

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.

I have two classes : Article and Author.
You mean that all the functions to add, retrieve, update and delete
lines in my db must be in the very same class, say DBInterface, and i
should do for example :
DBInterface.retrieveArticle(...),
DBInterface.addArticle(...), etc., and
DBInterface.retrieveAuthor(...),
DBInterface.addAuthor(...), etc. ?

I thought Wojtek meant i should have a package article.dbinterface in
which i would find the classes to do the changes.

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.

This can be accomplished without making maintainers' jobs more difficult, too.

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 ?

I strongly recommend that you study Wojtek's suggestions in depth. They are
sound and will accomplish the goals of isolation and security that you
espouse, with a sturdier and more compact architecture.

Inch'allah.

 

[Lew]

Thanks for your answers Lew. No need though to talk to me as if i were
stupid (maybe i am, but that's not quite polite, and not the best way
to make me understand my mistakes). If you don't understand my
questions, it's because we don't talk about the same thing. When i say
backend, i mean backend of a website. The place where administrators
connect via a http/html interface to update the information of the
website. Everybody i know working on websites calls this a backend
(implicitly : of the website).

No one is calling you stupid or even implying it. No one said anything about
your use of language, either. These matters are irrelevant to the discussion.

Use of terms, as opposed to use of language, is another matter. Definitions
of terms matter.

"Back end" is a more-or-less standard term, albeit imprecise, and means
roughly the data storage and related layers of an app. "Front end" is a
more-or-less standard term and loosely means the user interface layer. In the
common understanding of these terms, having a JSP in the "back end" is a
contradiction in terms.

If you use these terms in a different way you should explain how your use
differs from the common usage, otherwise you cannot blame someone for
misunderstanding you.

 

[subtenante]

Use of terms, as opposed to use of language, is another matter. Definitions
of terms matter.

Alright, sorry. To me, in the context of a website, i thought it was
clear that frontend was what the basic users have access to via their
web browser, and backend what the administrators of the website have
access to, also via their web browser.

 

[Lew]

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.

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.

Inch'allah.

God helps those who help themselves.