 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2007Design problem : security layers
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. TYPO CORRECTION : >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. > 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.  SignatureLew >> 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 ? [quoted text clipped - 4 lines] > >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 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. SignatureWojtek :-) > > So for the moment what i do is having two packages, namely frontend > > and backend, and the backend Objects all extend from the frontend [quoted text clipped - 4 lines] > 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. > > -- > Wojtek :-) 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 -- www.EdmundKirwan.com - Home of The Fractal Class Composition Ed wrote : >>> So for the moment what i do is having two packages, namely frontend >>> and backend, and the backend Objects all extend from the frontend [quoted text clipped - 14 lines] > > 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. SignatureWojtek :-) >subtenante wrote : >> Hi, [quoted text clipped - 7 lines] >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. subtenante wrote : >> The Data class holds all the information which the JSP needs. The >> information is loaded by the SQL class, inspected by the business class [quoted text clipped - 5 lines] > 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. >> With each use case in its own package, and minimal interaction between >> packages (except for the framework), I greatly reduce the probability [quoted text clipped - 5 lines] > 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. SignatureWojtek :-) >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. subtenante wrote : >> 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. Yes. But does your JSP use database aware classes? That is what i meant. >> 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 [quoted text clipped - 5 lines] > 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 :-) SignatureWojtek :-) >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. >> (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 :-) 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. Wojtek wrote: >> 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. 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. >> 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 ? 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. SignatureLew 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. >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". > 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 [quoted text clipped - 4 lines] > 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. SignatureLew >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. >> Use of terms, as opposed to use of language, is another matter. Definitions >> of terms matter. > > ... To me, That's nice. > 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. <http://en.wikipedia.org/wiki/Back_end> where it explains: > In software design, the front-end is the part of a software system that interacts directly with the user, and the back-end comprises the components that process the output from the front-end. The separation of software systems into "front ends" and "back ends" is a kind of abstraction that helps to keep different parts of the system separated. Like I said, if you use the term in an uncommon way you should explain it. It is anything but "clear" that your idiolectic definitions applied. SignatureLew >>> Use of terms, as opposed to use of language, is another matter. Definitions >>> of terms matter. >> >> ... To me, > >That's nice. Please, it was a humble admittance of personal ignorance. And a tentative to explain why i didn't explain a word i *thought* was clear, because the only acception of it i knew was the one i used. Should i explain every word i say in case there is another technical meaning i am not aware of ? >> 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 [quoted text clipped - 6 lines] >Like I said, if you use the term in an uncommon way you should explain it. It >is anything but "clear" that your idiolectic definitions applied. I already got your point, and i apologized. It's not enough ? We misunderstood each other, i'm very very very sorry. >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. >> 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. [quoted text clipped - 6 lines] >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. >> 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 [quoted text clipped - 3 lines] > >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 wrote: >> 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. 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. [quoted text clipped - 11 lines] > 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. SignatureLew >As to why you should or shouldn't do that, it depends. Your answers puzzle me, yesterday i really only need one DB account for the whole DB layer, now 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. I was absolutely not talking about one account per user. I was talking about one account for all the normal situations and one other per sensible operation. Look, i told you i am not trusting the people who are going to maintain the website later (i'm not even completely trusting myself). Few people here are aware of SQL injection. Even when they are, they are not completely sure of how to avoid it, and may let big holes in the website. So there is no way i put one big account for everything. >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. "User access to the DB doesn't exist" doesn't mean a lot to me. You only need one unchecked input from a user to have a hole, no matter how many layers you have between the HTML form and the SQL request. >> 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 [quoted text clipped - 5 lines] >classes on the front end will not even see the change, much less be involved >in it. Lower maintenance effort, lower TCO. So it is an implicit yes to the example i asked if it were right ? >> 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. We may not be talking about the same initial scheme then, because to me it means only changing one line per method : namely the one with the SQL request, plus the general DB interface class. I agree that it helps have then stored in only one file, but even like this, it's not very hard to find them in all your classes with a little regexp search in your work directory. >> Well, Wojtek himself admitted that his method was a lot of >> maintaining, with a lot of duplicated code for similar objects. Could [quoted text clipped - 3 lines] >architecture is a proven concept that has shown its value across gazillions of >projects. You're speaking like a salesman. I have my own requirements, i told you. It may or may not fit. I don't care of how many projects it worked for if it doesn't match for mine. >God helps those who help themselves. Amen. subtenante wrote : > Well, Wojtek himself admitted that his method was a lot of > maintaining, with a lot of duplicated code for similar objects. A lot of INITIAL maintaining. "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." The second paragraph is the reward for the initial work. I can add a complete Create, Update, Retrieve, Delete, List, Filter for a new table in less than a day. That is 5 web pages (Create/ Update are one page) and all the associated code (typically about 30 classes), with inter-woven user security, proven code flow (pattern), and a high degree of confidence that the code WILL work. With the liberal use of constants and scope limiting the compiler catches almost all of the copy/paste issues. And the duplicated code is for use case isolation. I can rip out almost any use case and, except for loss of funcionality, there is no impact on the rest of the system. All I have to do is remove it from the menu, and delete the entire package set. The same applies when adding new use cases. I will go to great lengths to preserve the robustness of code and its maintainability. About 25 years of progrmming has taught me it is more important than trying to achieve ideals. Ha, I've dated myself... SignatureWojtek :-) >subtenante wrote : >> Well, Wojtek himself admitted that his method was a lot of >> maintaining, with a lot of duplicated code for similar objects. > >A lot of INITIAL maintaining. When does the initial maintaining end then ? >I can add a complete Create, Update, Retrieve, Delete, List, Filter for >a new table in less than a day. [quoted text clipped - 4 lines] >that the code WILL work. With the liberal use of constants and scope >limiting the compiler catches almost all of the copy/paste issues. The thing is i can't get how you can make 30 classes for these 6 use cases. I mean, could you give me an example of the classes you find in these packages ? Do they also follow a certain sub-pattern that comes back frequently ? For the moment, the way i see it, i would hardly have one class in each package, which does not make that much sense. >And the duplicated code is for use case isolation. I can rip out almost >any use case and, except for loss of funcionality, there is no impact >on the rest of the system. All I have to do is remove it from the menu, >and delete the entire package set. Ok, i get it, which makes me think again that the main problem of java for this pattern is the impossibility to multi-inherit. What about inheritance for these use cases. Do you use it for particular things ? Or almost never ? >I will go to great lengths to preserve the robustness of code and its >maintainability. About 25 years of progrmming has taught me it is more >important than trying to achieve ideals. I'm not even sure what my ideals are... >Ha, I've dated myself... Better saying it than never having the occasion of ! subtenante wrote : > The thing is i can't get how you can make 30 classes for these 6 use > cases. I mean, could you give me an example of the classes you find in > these packages ? Do they also follow a certain sub-pattern that comes > back frequently ? For the moment, the way i see it, i would hardly > have one class in each package, which does not make that much sense. In the folowing, a leading x is the use case name, so where you see xEdit that could mean PersonEdit. Editing use case: xEdit xEditPage Command Data SQL SQL_Microsoft Validator List use case: xList xListAll xListPage xListAllPage xPrintView xPrintViewPage Command Data Row SortOrder SQL SQL_Microsoft ViewData Where a class has a name such as PersonEdit (or xEdit above), that is the servlet which is called by the application server (Tomcat). The servlet takes care of all navigation and calling the Command object. By navigation I mean that if the user clicks on Cancel, then that goes to another page. If an error occures, then we go to that page, etc. classes ending in Page hold page specific information such as field names. The JSP uses these names in the field name parameter (<input name="<%= PersonPage.USERID %>"> The Command class uses these field names to extract the information the user entered from the request and to place it in the Data object. The list function will paginate the rows, that is 1-20, 21-40, 41-45, and so on. The list all shows all the rows, and is used for printing the list. The SortOrder holds constants for which column is being sorted. A column on the List page (JSP) has a clickable header cell. That calls the xList servlet which calls the Command, which calls the SQL which uses a case statement (using the SoftFilter constants) to generate an "order by" clause which sorts by that column. Command contains the business rules. Validator validates the user input. ViewData holds detailed information for a single row. This is displayed below the list, and the user can click on a View button, or PrintView SQL is an abstract class containing the methods which will be used for SQL operations. For the Comand class to run SQL operations, it calls SQL.getInstance(TransactionLevel). The .getInstance determines the type of database vendor being used, and instantiates that class. SQL_x is a vendor specific class extending the SQL class, and has the actual SQL syntax for that vendor. If (for whatever reason) a different vendor is used, then only this set of classes need to be re-written. The vendor is specified in the configuration.properties file, along with connection parameters. So that is 19 classes. Of course there are other classes in the framework. For instance the Validator extends BaseValidator which has a lot of utility functions such as checkBlank(String value), which will make sure that value is not empty. If it is empty a message will be created which the user will see, and isError() will return true. Same for numberRange(long value, long minValue, long maxValue), dateOrder(Calendar start, Calendar end), and so on. I also use a database pool manager (proxool) which opens four connections intitially, up to a maximum of 20. All SQL operations get a connection from the pool, so connection overhead is minimal. SignatureWojtek :-) >In the folowing, a leading x is the use case name, so where you see >xEdit that could mean PersonEdit. > ... >I also use a database pool manager (proxool) which opens four >connections intitially, up to a maximum of 20. All SQL operations get a >connection from the pool, so connection overhead is minimal. Hmm. I do feel stupid now... That's more work than my time can afford i'm afraid. But that's clear and wil be very useful in the future. Thanks a lot ! > Hi, > [quoted text clipped - 11 lines] > 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. [quoted text clipped - 3 lines] > > Thanks. .ed -- www.EdmundKirwan.com - Home of The Fractal Class Composition 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.