Design Question for data structure:
Hello All,
I have a question as to the best design for some DAO objects that I need to decouple and I'm not sure the best way to do this. The problem is the objects are very tightly coupled together throughout the code and jsp's and I need to separate them out for easier maintenance.
The data structure is best described as a main user object that has subsets of groups assigned to it. These groups in turn have arrays of multiple key/value pairs that have further nested arrays of multiple key/value pairs. It is a tree structure, so currently they are using TreeSets to dump all these nested groupings of data, but you can't get to the data without using the tightly coupled DAO objects. The main user object has values assigned, based on the aggregate data within the groups. It's really nested objects and they are so tightly coupled to each other that one change breaks the code and jsp's in literally hundreds of places.
Now I'm working to add enhancements and decouple the existing DAO objects so it's easier to maintain, but I haven't come up with any design pattern to fit this yet.
Any ideas as to how to approach this?
Thanks,
James
Message was edited by:
jamesEston
Message was edited by:
jamesEston
# 1
> Hello All,
> I have a question as to the best design for some DAO
> objects that I need to decouple and I'm not sure the
> best way to do this. The problem is the objects are
> very tightly coupled together throughout the code and
> jsp's and I need to separate them out for easier
> maintenance.
Do your JSP pages directly access the DAO objects to get data?
> The data structure is best described as a main user
> object that has subsets of groups assigned to it.
> These groups in turn have arrays of multiple
> key/value pairs that have further nested arrays of
> multiple key/value pairs. It is a tree structure, so
> currently they are using TreeSets to dump all these
> nested groupings of data, but you can't get to the
> data without using the tightly coupled DAO objects.
In this tree structure, how many levels are their currently?
How many DAO objects are there currently?
Does the "main user object" need all of this data?
Is all of this data directly related to a "main user object"?
What is the nature of the data?
Can you describe the data?
# 2
> but you can't get to the
> data without using the tightly coupled DAO objects.
The DAOs are wrong then.
DAOs are for managing persistance of data. Once the data is in memory then managing that is the job of something else.
If you have a tree then that structure should be an independent class. The DAO uses the methods of that class to build the tree. Users of that class use the methods to access the data. The data itself can either be in the class itself or seperate (which would then mean that the class is a helper rather than a real object.)
# 3
I was trying not to overly complicate this by inlcuding the data structure, but two of the treesets data:
[model.Role@c7d5 code = [audit] description = [Access to data] name = [JIMS Audit], model.Role@4455 code = [basic] description = [Basic access] name = [JIMS Basic], model.Role@d131 code = [privacy] description = [Access to JIMS privacy data]
locationTypeList=[LocationType@b234 code = [amc] description = [Am. Part Code] name = [amc], LocationType@b1ea code = [mat] description = [Management Indicator Ticket] name = [mat], LocationType@313e code =
There are 3 DAO objects and more need to be added now. The user object will need data from all of them. The JSP's access this data directly. It's needed for security and location roles to determine access to functions and data within the app. The user has groups and these groups have security roles and locations that are separate and yet combine to give individual user access and admin rights. The key is that individual groups have separate data relevant to that group as a module that can be modified, added or removed and yet still combines with other groups data to give a total array of values for the individual user. I'm thinking the nature of the nested objects may require inner classes and/or a decorator pattern, but I'm still thinking though it.
Message was edited by:
jamesEston
# 4
> There are 3 DAO objects and more need to be added now.
> The user object will need data from all of them. The
> JSP's access this data directly. It's needed for
> security and location roles to determine access to
> functions and data within the app.
If the "user object" contains so much data and is designed with access to all of it's data, then it is possible to implement the Data Access Object design pattern with one object (DAO object). You could create a DAO for the "user object" only. When the "user object" needs to be persisted to the database, the DAO object does the job. When the "user object" need data from the database, the DAO object does the job.
Creating a DAO object for every piece of information contained in the "user object" seems like a bad design. However, it can't be fully judged without all the requirements, technical and non-technical. Just my opinion.
If there is data/information that is outside the "user object" and can be used in other ways, then it should have its own special DAO object counterpart, in my opinion.
JSP's pages should not access DAO objects directly. Having them do so conflicts with the three-tier programming basics.
