I have made this mistake more than once in the past.
In WebObjects, when you create a relationship between two entities using the EO Modeller, the tendency is to create the reverse relationship as well. Let me give you an example. Let's say you have two entities - Programmer and Project. One programmer can belong to only one project and a project can have many programmers (unless of course, the programmer is Shravan Kumar Mahankali, who usually can finish off entire projects, especially WO ones, single handedly!)
So, here, we need to create a to-one relationship from Programmer to Project. In the process, you have an option to create the reverse relationship (a to-many) from Project to Programmer. The advantage of creating these relationships is you can get the desired destination object(s) of the relationships by a simple method call - programmerObject.project() or projectObject.programmers(). This can be a great convenience. Without this, you would have to manually write code that would create the fetch specification and then call it - a good few lines of code!
The reason behind this is in the good old days of WebObjects, when everyone and his uncle used Apple's EOModeller tool, the reverse would always be checked by default. For all you rookies who have started using this fantabulous development platform recently, the EOModeller tool that comes with WOLips has an option that you need to select manually.
Think hard before creating the reverse relationship. Are you going to ever need the reverse relationship? Actually, even better, are you going to be using the reverse relationship frequently? After all, if ever you need the reverse relationship objects, you can always write the code for a fetch specification and get them.
The reason I am stressing on this so much is that WebObjects gets the reverse relationships in anticipation of them being used, even if they are not actually ever used. So, if you get the project object at any point in your code, WO will automatically get the programmer objects as well if the reverse relationship is defined. This may be all right if you have a few programmer objects associated with the project. However, if the number of objects can get large, this could be a recipe for disaster!
In WebObjects, when you create a relationship between two entities using the EO Modeller, the tendency is to create the reverse relationship as well. Let me give you an example. Let's say you have two entities - Programmer and Project. One programmer can belong to only one project and a project can have many programmers (unless of course, the programmer is Shravan Kumar Mahankali, who usually can finish off entire projects, especially WO ones, single handedly!)
So, here, we need to create a to-one relationship from Programmer to Project. In the process, you have an option to create the reverse relationship (a to-many) from Project to Programmer. The advantage of creating these relationships is you can get the desired destination object(s) of the relationships by a simple method call - programmerObject.project() or projectObject.programmers(). This can be a great convenience. Without this, you would have to manually write code that would create the fetch specification and then call it - a good few lines of code!
The reason behind this is in the good old days of WebObjects, when everyone and his uncle used Apple's EOModeller tool, the reverse would always be checked by default. For all you rookies who have started using this fantabulous development platform recently, the EOModeller tool that comes with WOLips has an option that you need to select manually.
Think hard before creating the reverse relationship. Are you going to ever need the reverse relationship? Actually, even better, are you going to be using the reverse relationship frequently? After all, if ever you need the reverse relationship objects, you can always write the code for a fetch specification and get them.
The reason I am stressing on this so much is that WebObjects gets the reverse relationships in anticipation of them being used, even if they are not actually ever used. So, if you get the project object at any point in your code, WO will automatically get the programmer objects as well if the reverse relationship is defined. This may be all right if you have a few programmer objects associated with the project. However, if the number of objects can get large, this could be a recipe for disaster!
Comments
Reg, this article, I think one-to-many relationships feature is one of the wonderful and powerful features of WebObjects, it is a pure object oriented way to interact with relationships provided by the well thought framework. WO is pure OOP.
Now, it is up to developers to choose it per their business needs.
I don't think any framework out there could complement WO. WO is developer friendly and at the same time it is a rapid application development framework best for any project, with its super powerful features and conveniences.
I would encourage Project Managers/ Technical Architects and Apple should re-think about their technology choices!