Question about Encapsulation
I have two classes that have a parent-child relationship sort of.
interface IProject{
void doIt();
}
class Projectimplements IProject{
List architectures;
public doIt(){
}
}
class Architecture{
Project project;
}
The question is how do I identify which project the architecture belongs to properly?
architecture is not a project but it does have a project and sometimes I need to know which project the architecture belongs to. So I return project not as a way to get the project from architecture, but as a way to identify which project the architecture belongs to. But it seems wrong to expose project from within architecture. But at the same time, project does not make up any of architectures behavior except if you call 'belonging' a behavior.
Maybe the answer is if you want to know which project the architecture belongs to you have to ask each project? This bidirectional relationship seems a bit odd. Maybe I can return from architecture a Project id or some kind of identifier but not the actual project?
In fact I dont think the architecture even needs to hold a reference to the project since its not using any behavior from the project. But I do need a sound way to indicate which project the architecture belongs to. preferrably from the architecture.
[1774 byte] By [
_dnoyeBa] at [2007-10-1 23:31:55]
i would do it this way:
interface IProject
{
long projectId = 0;
void doIt();
}
class Project implements IProject
{
public doIt()
{ }
}
class Architecture
{
Set projects;
}
the projects should be nullable whn an architect does not have one, and if he has more than one project, it wont be a problem either. as for the project itself, i dont think it needs architect info. this should make thing easier.
WTH you talkin about?This settles the issue for me. You are here to make trouble.
> WTH you talkin about?what you were doing was a many to many relationship, you would need to have an intermediate class to handle such a relationship. i reduced the complexity to a one to many relationship which will be sufficient to do what you are tryng to do...sighn...
> > WTH you talkin about?
>
> what you were doing was a many to many relationship,
> you would need to have an intermediate class to
> handle such a relationship. i reduced the complexity
> to a one to many relationship which will be
> sufficient to do what you are tryng to do...sighn...
Oh, you missed the part where the Architecture only blonged to a single Project. Considering this fact what would your recommendation be?
> > > WTH you talkin about?
> >
> > what you were doing was a many to many
> relationship,
> > you would need to have an intermediate class to
> > handle such a relationship. i reduced the
> complexity
> > to a one to many relationship which will be
> > sufficient to do what you are tryng to
> do...sighn...
>
> Oh, you missed the part where the Architecture only
> blonged to a single Project. Considering this fact
> what would your recommendation be?
there is a set of projects, which can contain 0 - lots of projects. if an architect belongs to only one project, then the set should contain only one project, and if the architect is working on multiple projects, the set can contain all the projects. you can identify projects by their id or other things you like. o figure this out a while a go when i was playing hibernate. you may want to take a look there too.
There seems to be a language problem here. There are no architects working on projects. There are Projects that contain multiple Architectures. An architect is one who designs architectures. I am not tracking architects.
> The question is how do I identify which project the
> architecture belongs to properly?
Your Architecture class needs to have a reference to the Project it belongs to. Just like in your example.
> architecture is not a project but it does have a
> project and sometimes I need to know which project
> the architecture belongs to. So I return project not
> as a way to get the project from architecture, but as
> a way to identify which project the architecture
> belongs to. But it seems wrong to expose project
> from within architecture. But at the same time,
> project does not make up any of architectures
> behavior except if you call 'belonging' a behavior.
Suppose I have an Invoice object. I need to know what Customer the invoice is for, so I make the invoice have a reference to the customer. Now you would probably say that doesn't change the behaviour of the invoice. Okay, suppose I agree with you. So what? That's still the most sensible way to do it.
Frankly I think that your idea that you can only have attributes that "change" an object's behaviour is a hindrance to your progress. If you want to know what Project an Architecture belongs to, you ask the Architecture and it says "I belong to Project X". If you don't like getProject() as the method name, you could call it something else.
> There are
> Projects that contain multiple Architectures.
class Project
{
Set architects;
}
class Architecture
{
Set projects;
}
the above then should suit your needs. you can use objects in your code, but they should mapped to some kind of unique ids in a relationanl database.
> The question is how do I identify which project the
> architecture belongs to properly?
>
By the way you phrased your question, you want to know what Project a given instance of Architecture belongs to. In this case, Architecture should have a reference to Project. I would do something like:
final public class Architecture {
final transient private Project parent;
public Architecture(final Project parent) {
super();
this.parent = parent;
}
// I am not providing an accessor method, so I have not yet 'exposed' the Project.
}
> architecture is not a project but it does have a
> project and sometimes I need to know which project
> the architecture belongs to. So I return project not
> as a way to get the project from architecture, but as
> a way to identify which project the architecture
> belongs to. But it seems wrong to expose project
> from within architecture. But at the same time,
> project does not make up any of architectures
> behavior except if you call 'belonging' a behavior.
>
Belonging behavior indicates a dependency, which in Java is normally achieved by composition (see above).
> Maybe the answer is if you want to know which project
> the architecture belongs to you have to ask each
> project?
You lost me there. You went from Project to Architecture back to Project. What way are you navigating?
> This bidirectional relationship seems a bit
> odd. Maybe I can return from architecture a Project
> id or some kind of identifier but not the actual
> project?
>
That is fine. However, the id properly belongs within Project itself. IMO.
> In fact I dont think the architecture even needs to
> hold a reference to the project since its not using
> any behavior from the project.
This requirement contradicts:
>But I do need a sound
> way to indicate which project the architecture
> belongs to. preferrably from the architecture.
Which is it? Something A cannot both be A and not A at the same time.
- Saish
Saisha at 2007-7-15 14:14:44 >
i think i understand op's requirement, and i dont think it is possible to do it in a single class, either architecture or project, it is a bi directional relationship, i think it has to be in two classes, unless you would do this:
class mgt()
{
Set archs;
Set ptojs;
public Set getRelatedProjs(Architecture archi)
{
return related projs;
}
public Set getRelatedArchis(Proj proj)
{
return related archis;
}
}
Saisha at 2007-7-15 14:14:44 >
General rule: if you will get rid of cyclic references, your design would be much easier.Denis Krukovsky http://dotuseful.sourceforge.net/ http://dkrukovsky.blogspot.com/
> General rule: if you will get rid of cyclic
> references, your design would be much easier.
>
> Denis Krukovsky
> http://dotuseful.sourceforge.net/
> http://dkrukovsky.blogspot.com/
Yes, this is what I am feeling and is why I posed the question. The issue is that the project reference is inside of the architecture, but it does not contribute to the architectures behavior. The architecture does not need it for anything except to identify which project it belongs to.
sometimes when i open a dialog window i like to show the project name the architecture belongs too.
I am just wondering if anyone has run into this situation and found any valuable lessons. I have discovered on a different pair of classes that if my child class does not know of its parent, the code was significantly simpler and did not remove any functionality. But in that case it was obvious who the parent was because the child was displayed in the parent. It never really stood alone.
How about some sort of third party "architecture registry"? When an architecture is associated with a project, you could register it, then you could ask this sort of question of the registry?That would get rid of the circular reference, at least.
I'm sorry but where aer the cyclical references? A bi-directional relationship is not cyclical.
As far as I am concerned, if you have an association that you need to navigate in both directions, make it bi-directional. What's the point in wrangling over what's 'proper'. You need to do it. If you don't make it bi-directional, you'll be iterating through one set of Objects to find the others. This is more 'correct'? Just make it bi-directional and get on with your life.
> I'm sorry but where aer the cyclical references? A
> bi-directional relationship is not cyclical.
>
> As far as I am concerned, if you have an association
> that you need to navigate in both directions, make it
> bi-directional. What's the point in wrangling over
> what's 'proper'. You need to do it. If you don't
> make it bi-directional, you'll be iterating through
> one set of Objects to find the others. This is more
> 'correct'? Just make it bi-directional and get on
> with your life.
bidirectionality adds complexity. Its not as simple as a reference and a getter.
Perhaps Ill add a method getArchitectureProjectName() and getArchitecturesProjectDescription(). thats really all that is needed I think...
For now it is just getProject() and returns the full project object.
> bidirectionality adds complexity. Its not as simple> as a reference and a getter.Why not?
> For now it is just getProject() and returns the full> project object.I still don't understand why this is a problem.
> > For now it is just getProject() and returns the
> full
> > project object.
>
> I still don't understand why this is a problem.
You must be looking for fire and brimstone. There is none. Its not an end of the world kind of issue. Its simply the added complexity of managing another reference. This has lifecycle implications for that reference as well. Plus my classes have DAOs. So if I get an architecture from the DB and create it, this now would require that I also get a Project as well and construct it. Constructing the project then can cause construction of all the architectures since it holds a list. So you have to deal with these situations.
Also if I get an architecture from the DB and get a different architecture from the DB both of which belong to the same project, but the project was constructed within the architecture, how to ensure they are equal or using the same reference? This stuff has to be dealt with. right now i force architecture to be retrieved through the project so the proj can add itself to the arch.
It goes away if the Architecture does not know of the Project.
> > > For now it is just getProject() and returns the
> > full
> > > project object.
> >
> > I still don't understand why this is a problem.
>
> You must be looking for fire and brimstone. There is
> none. Its not an end of the world kind of issue.
> Its simply the added complexity of managing another
> r reference.
If you have references to two Strings, those are also references. I'm don't see much complexity in references.
> This has lifecycle implications for
> that reference as well. Plus my classes have DAOs.
> So if I get an architecture from the DB and create
> e it, this now would require that I also get a
> Project as well and construct it. Constructing the
> project then can cause construction of all the
> architectures since it holds a list. So you have to
> deal with these situations.
Now we are getting somewhere. So yeah, it makes sense to hold some sort of id for the project so you don't have to instantiate it unless you need it. This is still a bi-directional association. It's just indirect.
> Also if I get an architecture from the DB and get a
> different architecture from the DB both of which
> belong to the same project, but the project was
> constructed within the architecture, how to ensure
> they are equal or using the same reference? This
> stuff has to be dealt with.
Whether you hold a refefence to the project in the Architecture class has no bearing on this. The simple solution is to have a Project Factory.
> right now i force
> architecture to be retrieved through the project so
> the proj can add itself to the arch.
>
> It goes away if the Architecture does not know of the
> Project.
If you just assign a key for the Project in the Architecture, then you can get it as needed without any of this complication or overhead and still not have to iterate through all the Projects to figure out which one owns the Architecture.
Perhaps that is where you are. I just was not understanding you. Now, is it correct that there are no cyclical references in this design?
hmm. Odd I had not thought of that yet. I recently started converting lots of the returned arrays to arrays of ID objects as opposed to arrays of the actualy sought object. So yes I can return ProjectID. Then i wouldnt have to hold a reference nor reconstruct any object.
my classes all use factories for construction so that wasnt the big issue. just that it had to take place at all when all i really want is a name and description from the project.
Lazily creating the Project object from the persistant storage should effect the mapping layer, not the domain model. If you're finding you have to convert your domain model to work with DB artifacts - the row ids - rather than objects something has gone wrong somewhere.Pete
> Lazily creating the Project object from the
> persistant storage should effect the mapping layer,
> not the domain model. If you're finding you have to
> convert your domain model to work with DB artifacts -
> the row ids - rather than objects something has gone
> wrong somewhere.
What would you propose then?
Expressing the interfaces in terms of Project and Architecture objects, but either holding the project id in the Architecture class and only resolving it on demand in the accessor method [1] or using a virtual proxy for the Project which only loads its data when its methods are queried [2].
Pete
[1] Fowler, Patterns of Enterprise Architecture, pattern: 'Lazy Load'
[2] GoF, pattern: 'Virtual Proxy'
> Expressing the interfaces in terms of Project and
> Architecture objects, but either holding the project
> id in the Architecture class and only resolving it on
> demand in the accessor method [1] or using a virtual
> proxy for the Project which only loads its data when
> its methods are queried [2].
OK, that's what I was thinking. I thought you meant something else.
> Lazily creating the Project object from the
> persistant storage should effect the mapping layer,
> not the domain model. If you're finding you have to
> convert your domain model to work with DB artifacts -
> the row ids - rather than objects something has gone
> wrong somewhere.
>
>
> Pete
none of this relates to the issue. These are all strategies used to deal with the side effects of holding and handing out a reference to the project from the architecture. I have employed many caching and lazy loading techniques that I have not gone into because they are not the main point of concern here.
If I implied I was returning row IDs then I am sorry for misleading you.
So your main point of concern is what, exactly?
You want to model bi-directional relationship.
You don't want to return a reference to the domain object for unstated reasons.
You said you were changing a lot of your code to use 'id objects' rather than references.
My understanding of 'id object' is as a wrapper for some id in the database. Hence I believe such a strategy is polluting the domain model with database artifacts.
There are other strategies that don't require polluting the domain model. If you're already aware of them, why aren't you using them?
Pete
> So your main point of concern is what, exactly?
>
See first post.
> You want to model bi-directional relationship.
>
not necessarily. I want to know if there are any other ways. And if people have had issues with bidirectional relationships.
> You don't want to return a reference to the domain
> object for unstated reasons.
Never said that. It complicates things and I am looking for other people that may have run into this issue and may have other perspectives. I am after more opinions than answers.
>
> You said you were changing a lot of your code to use
> 'id objects' rather than references.
>
> My understanding of 'id object' is as a wrapper for
> some id in the database. Hence I believe such a
> strategy is polluting the domain model with database
> artifacts.
>
> There are other strategies that don't require
> polluting the domain model. If you're already aware
> of them, why aren't you using them?
>
>
> Pete
You have made some big assumptions. I am using an id to identify certain database records and it is not polluting. Do you have another suggestion?
Your OP had no problems in it. Let the interface return a reference; if you have a circularity, use lazy loads to implement it. Make the interface simple and use encapsulation to hide any required complexities. Don't make every client have to do a look up on an id.
> You have made some big assumptions.
Yes. Whatever your real problem is not evident in anything you have posted so far, so I have to assume it's elsewhere.
>I am using an id to identify certain database records and it is not polluting.
By 'polluting' I mean you are allowing database artifacts - the id - to enter the object model. Therefore I consider what you have just described as polluting the domain model with data artifacts. The domain model shouldn't care about database ids.
In the UK you people have a national insurance number. When interfacing with certain external systems, this is used as an id. If you ask me what it is, I can tell you. Other systems can navigate to me by it. But in all other usecases, it is not used to establish a relationship with me. It is mearly an artifact of how one system views the running object. Your database IDs are the same - don't require them for all interactions with the object.
> Do you have another suggestion?
No, you have not stated what your problem is with using objects to model the domain directly. Until you actually give a reason why a pure OO approach is bad, I can only continue to suggest you use it.
Pete
> Your OP had no problems in it. Let the interface
> return a reference; if you have a circularity, use
> lazy loads to implement it. Make the interface simple
> and use encapsulation to hide any required
> complexities. Don't make every client have to do a
> look up on an id.
>
> > You have made some big assumptions.
> Yes. Whatever your real problem is not evident in
> anything you have posted so far, so I have to assume
> it's elsewhere.
>
> >I am using an id to identify certain database
> records and it is not polluting.
>
> By 'polluting' I mean you are allowing database
> artifacts - the id - to enter the object model.
> Therefore I consider what you have just described as
> polluting the domain model with data artifacts. The
> domain model shouldn't care about database ids.
>
I'm in the DAO layer, not the business layer.
Which means your whole architecture is an anti-pattern IMO. But if you're having to use DAO, then do what kludges you must.Pete
> Which means your whole architecture is an> anti-pattern IMO. But if you're having to use DAO,> then do what kludges you must.> > PeteSo you are saying DAOs are kludges? What isn't a kludge in your estimation?
> > Which means your whole architecture is an
> > anti-pattern IMO. But if you're having to use DAO,
> > then do what kludges you must.
> >
> > Pete
>
> So you are saying DAOs are kludges? What isn't a
> kludge in your estimation?
the DAOs, particularlly as illustrated in the samples, are defenetely kludges.
> So you are saying DAOs are kludges?
Sometimes. Having a DAO that is separate from the domain model and that has a reference to an 'id object' that only provides an accessor to a database id isn't going to get you much benefit over plain SQL.
You're going to have to build the runtime domain model object graph somehow, and doing it by means of Project.getProjectFromId( architecture.getProjectID()) in the DAO client code smells to me. If the project ID really is only to identify the data in a database table, it shouldn't be visible to the domain objects.
> What isn't a kludge in your estimation?
Using encapsulation - the id is an implementation artifact, not (usually) part of the domain model and should be hidden in the mapping layer. If you want type checking on the ids, use referential integrity in the DB rather than creating a 'ProjectID' class in a DAO.
Using metadata or code generation based techniques to generate the mappings to the persistent data rather than a duplicate class heirarchy of 'data objects' and 'business objects'.
There's a lot of times that the standard Java solution patterns are limited because the language is based on strong types and interfaces, without any built-in generative technology. The compiler's type system isn't the only means of asserting type constraints. Interfaces are good for decoupling at service clients and providers at runtime, but runtime decoupling against data schema change is rarely needed, and can be implemented at compile time with far fewer human written KLOCs.
Pete
> > So you are saying DAOs are kludges?
>
> Sometimes. Having a DAO that is separate from the
> domain model and that has a reference to an 'id
> object' that only provides an accessor to a database
> id isn't going to get you much benefit over plain
> SQL.
I think we are on the the same page here but I guess where I am getting confused is that if you want to lazy load a resource from the DB from a call to a domain (?) Object, it seems normal to store some sort of id internally so they resource can be retrieved without a lot of hullabaloo.
> You're going to have to build the runtime domain
> model object graph somehow, and doing it by means of
> Project.getProjectFromId(
> architecture.getProjectID()) in the DAO client code
> smells to me. If the project ID really is only to
> identify the data in a database table, it shouldn't
> be visible to the domain objects.
I'm not sure what you mean by 'visible' here.
> > What isn't a kludge in your estimation?
This question seems a little flip no that I look at if with fresh eyes. Thanks for not dismissing it.
> > So you are saying DAOs are kludges?
>
> Sometimes. Having a DAO that is separate from the
> domain model and that has a reference to an 'id
> object' that only provides an accessor to a database
> id isn't going to get you much benefit over plain
> SQL.
>
You seem to be of the belief that databases are for persistence only. Perhaps that is the case in many applications. But it is by no means a rule.
My DAO Layer is handled by JDO. I can implement everything I need by staying in the object domain and forget exposing any table information and iterating over tons of lists of objects that are abstractions of tables(or vice versa depending on how you view it). Or I can run a few queries that operate about 1000x times faster..
> You seem to be of the belief that databases are for persistence only.
No, I've already mentioned that referential integrity is better served in the DB.
> My DAO Layer is handled by JDO. I can implement everything I need by staying in the object domain and
> forget exposing any table information and iterating over tons of lists of objects that are abstractions of tables(or vice versa depending on how you view it).
I'd still go further and not expose the IDs. If you are returning a list of FooID objects, as you said you were earlier, then you are going to have to iterate over than list and call into your mapping layer from the client code in order to resolve them to Foo objects.
> Or I can run a few queries that operate about 1000x times faster..
What you have said so far in this thread seems to contradict what you are now saying. I understood what you said about the way you're changing your design to be counter productive to the things you are now say you value. If you're sure that returning some IDs then iterating over them to get the object reference reduces the amout of iteration and enables bulk queries then, well, it's your system and do what your profiling says is best.
Pete
> I'd still go further and not expose the IDs. If you
> are returning a list of FooID objects, as you said
> you were earlier, then you are going to have to
> iterate over than list and call into your mapping
> layer from the client code in order to resolve them
> to Foo objects.
Its not smart to return a list of ids just to use them to ask the db to return the objects. I have done this, but its only a cheap substitution for lazy loading when nothing else is available. I also use an id so the user can automatically return to editing his component when he opens the application the next time. This is not a petstore or cashregister. Its a CAD program.
These queries seem to be outside of persistence and I am going to investigate if I can place them in their own layer somehow. They are really using the database as a database whereas the main DAOs are doing their best to act as if there is no database (i.e. hiding their ids and whatnot).
Perhaps that is what you are seeing that you disagree with.
by using instanceof u can find out the belong to
> by using instanceof u can find out the belong tosmashing...
> > by using instanceof u can find out the belong to> > smashing...HAHAHAHAHAHHAHAHAHA
Hi,You need only create and Object (Container) and you container both project and architect, let the Bussined Layer to make the diference and reference your relevant object is the Row and Column not Project ....
> Hi,
>
> You need only create and Object (Container) and you
> container both project and architect, let the
> Bussined Layer to make the diference and reference
> your relevant object is the Row and Column not
> Project ....
You lost me.
In general my DAOs done need ids while I am doing CADish stuff. but when I start asking questions about the objects, then I need the ids because its better to use queries. This is indeed two seperate things, but my program is like that.
The questions are starting to get real strange toward the end now.
> > So you are saying DAOs are kludges?
>
> Sometimes. ...
>
> > What isn't a kludge in your estimation?
>
> Using encapsulation - the id is an implementation
> artifact, not (usually) part of the domain model and
> should be hidden in the mapping layer. If you want
> type checking on the ids, use referential integrity
> in the DB rather than creating a 'ProjectID' class in
> a DAO.
>
> Using metadata or code generation based techniques to
> generate the mappings to the persistent data rather...
To my mind the second represents DAOs. Just because I don't code them it doesn't mean they don't exist.
As for the first I tend to avoid it because it is usually used because one doesn't know how to do the second and doesn't want to manually code all of the code. And just because it isn't explicit and exists only at runtie doesn't mean that it still isn't a DAO.
> As for the first I tend to avoid it because it is
> usually used because one doesn't know how to do the
> second and doesn't want to manually code all of the
> code. And just because it isn't explicit and exists
> only at runtie doesn't mean that it still isn't a DAO.
Do you use a standard tool for code generation. I looked at Turbine/Velocity a long time ago but I found myself frustrated trying to find the documentation for what I wanted to do. I've written a code generator that worked quite well at my last job but I don't want to do that again and want something more flexible.
What purpose does a code generator serve? I have a persistence layer handled by JDO. I really like to reduce the number of tools used to a minimum too. I never used code generation before but i will at work be generating some code from a model in about two weeks.
> Do you use a standard tool for code generation.
I coded every single one. Quite few of them now too. Maybe 10?
> I looked at Turbine/Velocity a long time ago but I
> found myself frustrated trying to find the
> documentation for what I wanted to do. I've written
> a code generator that worked quite well at my last
> job but I don't want to do that again and want
> something more flexible.
XDoclet (or whatever it is called)?
> To my mind the second represents DAOs. Just because I don't code them it doesn't mean they don't exist.
Quite possibly. The same is true of the machine code the JVM creates - it exists, but you (usually) don't have to worry about it - it's not a useful level of abstraction, and you don't waste your time creating it by hand.
> As for the first I tend to avoid it because it is usually used because one doesn't know how to do the
> second and doesn't want to manually code all of the code. And just because it isn't explicit and exists
> only at runtie doesn't mean that it still isn't a DAO.
Thinking about when I've used these techniques, I do favour the generation route. But I write the business code by hand then automatically merge the generated data access code into the same object, so you get a live business object that has transparent persistence (most of the time not to DB but to custom CAE storage) rather than a data-only object.
There's some interesting work on traits as a means of clean multiple inheritance that has recently come onto my radar (eg fortress) that may allow that sort of merging within the language rather than using external tools.
Pete
> > Do you use a standard tool for code generation.
>
> I coded every single one. Quite few of them now too.
> Maybe 10?
Anything that's a general(-esque) solution?
> > I looked at Turbine/Velocity a long time ago but I
> > found myself frustrated trying to find the
> > documentation for what I wanted to do. I've
> written
> > a code generator that worked quite well at my last
> > job but I don't want to do that again and want
> > something more flexible.
>
> XDoclet (or whatever it is called)?
That's really annotations before annotations. I was looking for a more general solution. Not necessarily Java generation. I once talked to a co-worker about using XSLT for code generation but I never really followed up on it.
> That's really annotations before annotations. I was
> looking for a more general solution. Not necessarily
> Java generation. I once talked to a co-worker about
> using XSLT for code generation but I never really
> followed up on it.
I looked at the XDoclet info a little bit and it looks like it may be a general solution. Thanks.
I use a Arraylist of Rows, Rows could be get By name (similar to a hashtable).Each Column hash a type (double ... integer ... )I only call to database with the Select String and get the Result as a ArrayList of Rows.This aproach is easy to me, and ligth
> I once talked to a co-worker about using XSLT for code generation but I never really> followed up on it.I've used XSLT from UML + MathML quite extensively.Pete
> > > Do you use a standard tool for code generation.
>
> >
> > I coded every single one. Quite few of them now too.
> > Maybe 10?
>
> Anything that's a general(-esque) solution?
I started that at one point but gave up. Mainly because the input source tends to vary greatly (like a SQL schema, a custom source file, a design tool report, etc.)
>
> > XDoclet (or whatever it is called)?
>
> That's really annotations before annotations. I was
> looking for a more general solution. Not necessarily
> Java generation.
I wasn't aware that it was limited to java. I just presumed that you merely needed to add something to get it to produce code.
> I use a Arraylist of Rows, Rows could be get By name
> (similar to a hashtable).
>
> Each Column hash a type (double ... integer ... )
>
> I only call to database with the Select String and
> get the Result as a ArrayList of Rows.
>
> This aproach is easy to me, and ligth
Which, to me, sounds like the meta-data solution. And as I pointed out it is easy for the initial coder but the limitation is that it only exists at runtime, and thus detecting errors is more difficult.
Hi,
I make a static metadata for this problem. I use XML fo this.
But, It is easy for my programmers only need know Arralist, Hashtables and primitive object.
My expert programmers make some taglibs and some class that use the junior programmer.
They do not need know complex systems, only Xml and some class.
Thanks
> I make a static metadata for this problem. I use XML
> fo this.
>
> But, It is easy for my programmers only need know
> Arralist, Hashtables and primitive object.
Again - which suggests metadata.
How do you validate it at compile time (not run time)?
Hi,
My problem was that I have 20 programmer that only know PERL and C.
This people need migrate as soon as possible. I explain Some Object and Concept and I make a Dynamic Framework with this simple object.
We check the types at runtime using the static XML metadata.
Now, I think that I use BPEL and JSF but this is "another war".
My problem now is that I have some functional people tha know the Bussines Process, and I need that this people make the work flow of the process. Too, I have some graphical deginner.
That is, different problems, diferent solution, depens on people, technlogy and the mistakes that I see in the past.
Thanks
> I have 20 programmer that only know PERL and C.
>
> This people need migrate as soon as possible.
> My problem now is that I have some functional people
> tha know the Bussines Process, and I need that this
> people make the work flow of the process. Too, I have
> some graphical deginner.
>
i see you have a great sense of humer.
> My problem was that I have 20 programmer that only
> know PERL and C.
>
> This people need migrate as soon as possible. I
> explain Some Object and Concept and I make a Dynamic
> Framework with this simple object.
And so why don't you do the data layer and just have them use the exposed API?
By the way if you are doing an entire java project 21 developers and only one of them knows Java at all then you have a management problem.
Makes me also wonder why you didn't just do it in perl and C.
Hi,
C and PERL as a maintenance very complex. My programmer are frustrated with this language my boss need change the chip of them.
I promise Java (java programmer was more pay than C and PERL ) and they collaborate without problems.
PERL and C program are not develop for my programmers.
And so why don't you do the data layer and just have them use the exposed API?
At this momment JCA do not exist, JSF do not exist and I need use this Object for a lot of Source, no only for database. I use for JSM for JavaMail, for call to PERL program for call HTTP, for call SOAP ...
The JDBC api is very complex, they need close connection, open connection, ... make a resultset ... I make a XML that enable call the database.
We solve the problem of management, step by step. Now, we have 20 Java programmer that use Struct, Portal ...
This web have 26000 visit per day and we have 10 times more visit that C and PERL web.
You didn't just say JDBC API is more complicated than XML API did you?
> Hi,
>
> C and PERL as a maintenance very complex. My
> programmer are frustrated with this language my boss
> need change the chip of them.
Presumably you mean compared to Java.
And how precisely did you measure that?
>
> I promise Java (java programmer was more pay than C
> and PERL ) and they collaborate without problems.
>
> PERL and C program are not develop for my
> programmers.
>
> > And so why don't you do the data layer and just have
> > them use the exposed API?
>
> At this momment JCA do not exist, JSF do not exist
> and I need use this Object for a lot of Source, no
> only for database. I use for JSM for JavaMail, for
> call to PERL program for call HTTP, for call SOAP
> ...
Which is meaningless.
Again you are using metadata. The exposed interface is the exposed interface. How you choose to expose it is up to whoever is writing it.
>
> The JDBC api is very complex, they need close
> connection, open connection, ... make a resultset ...
> I make a XML that enable call the database.
>
Which has nothing to do with what I said.
> We solve the problem of management, step by step.
> Now, we have 20 Java programmer that use Struct,
> Portal ...
>
You just said you have 20 C/Perl programmers.
> This web have 26000 visit per day and we have 10
> times more visit that C and PERL web.
I would guess that has nothing to do with the language that you chose to implement it in.
> My understanding of 'id object' is as a wrapper for
> some id in the database. Hence I believe such a
> strategy is polluting the domain model with database
> artifacts.
>
Wow. This is what I'm doing in places. Oops.
*Learning every day*. I'll be sure to check out the patterns you've mentioned in reply 23...
In that momment, I make a test, I put some programmer to use JDBC and I make simple (only for my app) XML files. I need change the JDBc app, they do not close connection etc.now, We use the XML api.
Hi,
Yes I compare with Java. The libraries that prodive Java are simplest and fastest.
The 20 programmers was worker in Java since 2002, I think that they became good java programmer (In the past junior C and PERL programmer)
I expose a simple interface (ouput call(input)).
Both input and output are Hashtable (similar to).
I make a simple test, tow programmer make an application in JDBC, they make a lot of not close connection.
The web in Java is more maintenable, simple, understable that C and PERL.
I think that Java add me, but the design too. We have 10 times more visit and we have 10 times more transaction.
At the begin in C and PERL we only have 4 different transaction, today we have more than 100.
It is a Bank with 400 000 user.
Thansk you
> > My understanding of 'id object' is as a wrapper
> for
> > some id in the database. Hence I believe such a
> > strategy is polluting the domain model with
> database
> > artifacts.
> >
>
> Wow. This is what I'm doing in places. Oops.
>
> *Learning every day*. I'll be sure to check out the
> patterns you've mentioned in reply 23...
Easy...Just because you let out the database ID does not make your code bad. JDO exposes whatever columns you want, does that make JDO a bad architecture? If you can get rid of the ID go ahead. If you are using the database as more than a storage mechanism, but for what databases are good at, queries, then you probably can't get rid of the id...
> Hi,
>
> Yes I compare with Java. The libraries that prodive
> Java are simplest and fastest.
>
> The 20 programmers was worker in Java since 2002, I
> think that they became good java programmer (In the
> past junior C and PERL programmer)
>
> I expose a simple interface (ouput call(input)).
>
> Both input and output are Hashtable (similar to).
>
And that implies that you are using meta data.
> I make a simple test, tow programmer make an
> application in JDBC, they make a lot of not close
> connection.
Repeating for the second and perhaps third time that has nothing to do with what I am talking about.
My interfaces always deal with the connection problem and yet they don't need meta data to do it.
>
> The web in Java is more maintenable, simple,
> understable that C and PERL.
>
And again that has nothing to do with the choice of language.
> I think that Java add me, but the design too. We have
> 10 times more visit and we have 10 times more
> transaction.
>
Which really has nothing to do with the implementation.
You are confusing history with maintainability (and cost.)
Apache is not written in java and yet the number of users that use it every day exceeds your numbers by several orders of magnitude (probably 5 or 6 at least.) So based on your reasoning you should immediately switch to C (or C/C++) because that is what Apache is written in.
interface IProject{
void doIt();
}
class Project implements IProject{
IArchitecture[] archs;
public doIt(){
}
}
class Architecture implements IArchitecture{
IProject[] projects;
}
But always, this type of relationship is prone to memory leak.
Hi
You says
>Apache is not written in java and yet the number of users that use it >every day exceeds your numbers by several orders of magnitude
>(probably 5 or 6 at least.) So based on your reasoning you should >immediately switch to C (or C/C++) because that is what Apache is >written in.
Apache is a OpenSource project that have a lot of best architect, programmer etc ...
>And that implies that you are using meta data.
Yes, I use the meta data (my Data Model BBDD).
How many Class you need for manage a table and for manage two tables.
> My interfaces always deal with the connection problem and yet they don't need meta data to do it.
It is mean that you have an interface that encapsulate JDBC.
>You are confusing history with maintainability (and cost.)
No, I have real data that I get with my expertise.
> Hi
> You says
>
> >Apache is not written in java and yet the number of
> users that use it >every day exceeds your numbers by
> several orders of magnitude
> >(probably 5 or 6 at least.) So based on your
> reasoning you should >immediately switch to C (or
> C/C++) because that is what Apache is >written in.
>
> Apache is a OpenSource project that have a lot of
> best architect, programmer etc ...
>
> >And that implies that you are using meta data.
>
> Yes, I use the meta data (my Data Model BBDD).
Which, back to my original point, is not often a good idea.
>
> How many Class you need for manage a table and for
> manage two tables.
>
> > My interfaces always deal with the connection
> problem and yet they don't need meta data to do it.
>
> It is mean that you have an interface that
> encapsulate JDBC.
>
Yes, but they don't use metadata.
> >You are confusing history with maintainability (and
> cost.)
> No, I have real data that I get with my expertise.
The data you posted here is meaningless in regards to the suitability of language over another. Now perhaps you have other stats, something along the lines of number of bugs, time to fix each, severity etc which are based either on comparable projects or a large enough code pool that the results are not skewed by various non-casuality factors.
If so then you should have posted that and not the data that you did post.
Sorry,
I use the comparation with C and PERL in order to explain my architecture and the success that I obtain.
I think that you do not use metadata and use a mapping between concept and data model. I make this in a project 5 year ago.
The problem in this case is that I make a program for manage data in tables and not for manage object. This mean that I need a lot of classes and a lot of method to access data.
I make a refactoring and I extract the relevant object of my applycation, at this point I find out that my object was ROWS and TABLES.
I think that as simple as posible is the best for maintenance.
Thanks you
If you have some question I could respond directly.
> Sorry,
>
> I use the comparation with C and PERL in order to
> explain my architecture and the success that I
> obtain.
>
> I think that you do not use metadata and use a
> mapping between concept and data model. I make this
> in a project 5 year ago.
If you are using a hash then you are using metadata. You are using a value to map to another.
>
> The problem in this case is that I make a program for
> manage data in tables and not for manage object. This
> mean that I need a lot of classes and a lot of method
> to access data.
>
> I make a refactoring and I extract the relevant
> object of my applycation, at this point I find out
> that my object was ROWS and TABLES.
>
> I think that as simple as posible is the best for
> maintenance.
>
> Thanks you
>
> If you have some question I could respond directly.
Your explaination suggests that you are storing fields by hash rather than directly. This makes it easy for you to type and makes it harder for everyone, including yourself, to maintain.
Hi,
I do not explain well. Externanly, we use the database for save the rows, but internally we have a XML artifact that map database object to old java object. Simple, we use similar XML artifact to map from COBOL copys to old java Object, to map JavaMail api to old java object, we use too a XML artifact to map HTTP to old java object,
this means that in the bussines layer we only manage old java object, the presentation layer only work with java object.
Data Access have been configured used XML.
This aproach is very easy and simplest, we need low maintenance.
Thanks you
Hi,
I forgot some thing to explain:
I think that you do not use metadata and use a
> mapping between concept and data model. I make this
> in a project 5 year ago.
> The problem in this case is that I make a program for
> manage data in tables and not for manage object. This
> mean that I need a lot of classes and a lot of method
> to access data.
This approch I use 5 year ago, in the following project I use the solution that I explaing before.
I mix a project that we make a lot of mistakes of design with the new (now) project.
I am designed a new project, but I use Simple Object that I could transform directly to SOAP.
Thanks you
