After modifying our last architecture scheme to be more in line with our current requirements, I come up with the following, Please comment.
Data Access Objects know how to persist and load a given entity, one DAO per entity.
Transfer Objects only contain data. One transfer object per entity.
Entity Factories know how to locate and create transfer objects, one factory per entity.
Factories are configurable at server load time, via metadata tables (or prop files)
Configurable data includes: column names and request parameter names
Business Objects know what can be done for a given "module", one BO per module
BOs can be configured at server load time, via metadata tables (or prop files)
Configurable data TBD after further design
Module Facade provides a light facade over the business object functionality
Module Facade's main purpose is to normalize any exceptions thrown by the system
Struts action will obtain a reference to the Module Facade(s) that it needs, and all system capabilities will be accomplished through that. Since the system is fairly simple (as currently spec'd) one facade is likely enough - though this will form a bottleneck wrt check-ins - so maybe one facade per module. Module breakdown might go something like:
Incident Recording
User Maintenance
Company/Product maintenance
Intelligence Maintenance
Reporting
Logon/Security
So, the rough task list is:
Construct TO/Entity Factories/DAO
Construct UI, stub in facade calls in action classes
Construct BOs to support Facade.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, we have an entity TO, like, say - Incident. This thing might have several related entities and such things (company, status, priority). These are in the IncidentTO as longs, in order to store just the Id (thus there is a one to one mapping between TO fields and database fields). However, once we have an IncidentTO we are likely going to want the status text and such, so - should we give the TO a Status field that is populated at Incident creation time? Or lazy instantiate the thing when requested? Or not bother at all, and the code one level up (BO most likely) would be responsible for creating and populating these things?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, is our model concerned primarily with representing the structure of the database or are we concerned with representing what the database is attempting to represent -- the latter methinks. So, yes -- a Status field populated at incident creation time -- what do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wonderful - so - when you call the create (or lookup, or whatever) method to get a particular incident, will that return an object to you that contains a collection of all that incident's Intel, a Company object (with all its Intel), and so on?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Crap -- I dunno. That could get hairy -- cos where do you stop on the chain -- I mean if you load an Incident and it's associated Company -- do you load the company's projects and then their Incidents, etc.
Could get just way too heavy.
Shit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We could load up the attributes one level deep, and leave the rest to be lazily instantiated.
So, when I say "give me an Incident" I get all the Incident fields, and any associated status/priority attributes already filled out. Then, as soon as I say "ok, now I want this incident's product (or Intel, or whatever) then we get that object at that time, and so on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Email Convo b/w me and Lee -- read from the bottom up.
-----------------------------
K, so, let's think here -- perhaps we want to persist/lookup from a local database, perhaps we need a remote database, perhaps we're looking up data exposed via a web service in Taiwan; we don't want to just assume that all of our data is JDBC-based. So, that said -- let us be logical:
To get the ball rolling -- what do you think about having an interface for looking-up and updating/deleting/storing (sep intfc?) IncidentTO objects -- this thing is created at runtime via some factory (based on system properties I would think). So, that'll get us independence from the backend -- we'll just provide "dao providers" or whatever that promise to handle the functions we've defined in the IncidentProvider interface. Those things will handle all the potentially weird mapping, etc.
Shit, you could have a RequestMapProvider that digested this Map and knew how to create an InstanceTO based on it. That's cool. I guess the term "create" here could get confusing -- there's a create that means commit and create that means a tmeporary in-memory yet-to-be-persisted object representation. the latter doesn't belong in these provider classes really -- maybe that's where the entity factory comes into play.
Sorry to throw a wrench in things.
-----Original Message-----
From: Harkness, Lee [mailto:L.Harkness@TriCorInd.com]
Sent: Thursday, June 19, 2003 11:44 AM
To: Cory Wilkerson
Subject: RE: the final version
Ok, I'd not thought this all the way through, I was just thinking of
creating TOs (or doing a lookup).
So, the DAO is responsible for loading from and saving to the datastore - it
takes a TO and persists it, or it takes an ID and instantiates a TO and
returns that.
The factory is there to help you create (lookup in the case of a key, create
in the case of a Map or XML stream or any other representation of the TO)
the TO - you just give the create method of the factory the stuff it needs
to hand you back a TO (an ID, a Map, a String, and InputStream, whatever).
So, I am not sure where we could put in the column name mapping/Map key name
mapping/XML element name mapping stuff - or even if we should... What do
you think? If the DAO returns a ResultSet (like you show) then this could
go in the factory, but I sorta thought the DAO would return a TO, in which
case this would go in the DAO. So, do we make a set of DAOs? A MapDAO, an
XMLDAO, or .... hmmm. I dunno. I'm but a simple man.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After modifying our last architecture scheme to be more in line with our current requirements, I come up with the following, Please comment.
Data Access Objects know how to persist and load a given entity, one DAO per entity.
Transfer Objects only contain data. One transfer object per entity.
Entity Factories know how to locate and create transfer objects, one factory per entity.
Factories are configurable at server load time, via metadata tables (or prop files)
Configurable data includes: column names and request parameter names
Business Objects know what can be done for a given "module", one BO per module
BOs can be configured at server load time, via metadata tables (or prop files)
Configurable data TBD after further design
Module Facade provides a light facade over the business object functionality
Module Facade's main purpose is to normalize any exceptions thrown by the system
Struts action will obtain a reference to the Module Facade(s) that it needs, and all system capabilities will be accomplished through that. Since the system is fairly simple (as currently spec'd) one facade is likely enough - though this will form a bottleneck wrt check-ins - so maybe one facade per module. Module breakdown might go something like:
Incident Recording
User Maintenance
Company/Product maintenance
Intelligence Maintenance
Reporting
Logon/Security
So, the rough task list is:
Construct TO/Entity Factories/DAO
Construct UI, stub in facade calls in action classes
Construct BOs to support Facade.
So, we have an entity TO, like, say - Incident. This thing might have several related entities and such things (company, status, priority). These are in the IncidentTO as longs, in order to store just the Id (thus there is a one to one mapping between TO fields and database fields). However, once we have an IncidentTO we are likely going to want the status text and such, so - should we give the TO a Status field that is populated at Incident creation time? Or lazy instantiate the thing when requested? Or not bother at all, and the code one level up (BO most likely) would be responsible for creating and populating these things?
Well, is our model concerned primarily with representing the structure of the database or are we concerned with representing what the database is attempting to represent -- the latter methinks. So, yes -- a Status field populated at incident creation time -- what do you think?
Wonderful - so - when you call the create (or lookup, or whatever) method to get a particular incident, will that return an object to you that contains a collection of all that incident's Intel, a Company object (with all its Intel), and so on?
Crap -- I dunno. That could get hairy -- cos where do you stop on the chain -- I mean if you load an Incident and it's associated Company -- do you load the company's projects and then their Incidents, etc.
Could get just way too heavy.
Shit.
We could load up the attributes one level deep, and leave the rest to be lazily instantiated.
So, when I say "give me an Incident" I get all the Incident fields, and any associated status/priority attributes already filled out. Then, as soon as I say "ok, now I want this incident's product (or Intel, or whatever) then we get that object at that time, and so on.
Email Convo b/w me and Lee -- read from the bottom up.
-----------------------------
K, so, let's think here -- perhaps we want to persist/lookup from a local database, perhaps we need a remote database, perhaps we're looking up data exposed via a web service in Taiwan; we don't want to just assume that all of our data is JDBC-based. So, that said -- let us be logical:
To get the ball rolling -- what do you think about having an interface for looking-up and updating/deleting/storing (sep intfc?) IncidentTO objects -- this thing is created at runtime via some factory (based on system properties I would think). So, that'll get us independence from the backend -- we'll just provide "dao providers" or whatever that promise to handle the functions we've defined in the IncidentProvider interface. Those things will handle all the potentially weird mapping, etc.
-Dorg.jroots.dets.InstanceProvider=yournewimplementationifyouwanttoprovideit
Shit, you could have a RequestMapProvider that digested this Map and knew how to create an InstanceTO based on it. That's cool. I guess the term "create" here could get confusing -- there's a create that means commit and create that means a tmeporary in-memory yet-to-be-persisted object representation. the latter doesn't belong in these provider classes really -- maybe that's where the entity factory comes into play.
Sorry to throw a wrench in things.
-----Original Message-----
From: Harkness, Lee [mailto:L.Harkness@TriCorInd.com]
Sent: Thursday, June 19, 2003 11:44 AM
To: Cory Wilkerson
Subject: RE: the final version
Ok, I'd not thought this all the way through, I was just thinking of
creating TOs (or doing a lookup).
So, the DAO is responsible for loading from and saving to the datastore - it
takes a TO and persists it, or it takes an ID and instantiates a TO and
returns that.
The factory is there to help you create (lookup in the case of a key, create
in the case of a Map or XML stream or any other representation of the TO)
the TO - you just give the create method of the factory the stuff it needs
to hand you back a TO (an ID, a Map, a String, and InputStream, whatever).
So, I am not sure where we could put in the column name mapping/Map key name
mapping/XML element name mapping stuff - or even if we should... What do
you think? If the DAO returns a ResultSet (like you show) then this could
go in the factory, but I sorta thought the DAO would return a TO, in which
case this would go in the DAO. So, do we make a set of DAOs? A MapDAO, an
XMLDAO, or .... hmmm. I dunno. I'm but a simple man.