- Don’t fight the tool – WebObjects and EOF are very flexible and rich in capablilites. Get to know the way they work and work with them. Don’t fight them – they will win. Read the sample code from Apple and the source for Project WONDER. When you write your code emulate their style. The really good stuff is just below the surface (Key Value Coding for example). That’s where the power lives, dig a little, you will be rewarded.
- Follow the commandments – A few simple rules that will prevent a world of hurt.
- Let someone else write the code – I’ve mentioned a number of sources of WebObjects frameworks in my posts (Project WONDER, SwitchableStrings, WOCode ). They provide an amazing amount of functionality that you don’t need to implement yourself, that’s the entire point of OO design isn’t it? Also, when you build something useful, factor it out into your own reusable framework – why would you want to write something twice? Finally, use EOGenerator – no really – use it. There is no excuse not to.
- Model it right the first time – Every time I’ve been tempted to cut corners on my model, it’s come back to bite me. A strong Model will allow your App to almost write itself. My general rule of thumb: If I can’t get from one object to a “related” one via KVC, I’m going to be grumpy.
- If it is getting complicated, you’re probably doing it wrong
- You’re fighting the tool aren’t you?
- Maybe WebObjects is the wrong tool.
Please, don’t try to hack around the WebObjects architecture. i.e. If you really need multiple concurrent access to your database everywhere in your application – use something other than EOF.
7 thoughts on “WebObjects thoughts.”
Comments are closed.
David, great post! The last one is my usual sanity check – often stuff just feels too complicated, but I can’t put my finger on it. Step back, rethink it, and it’s often a very simple solution.
What do you mean by “Please, don’t try to hack around the WebObjects architecture. i.e. If you really need multiple concurrent access to your database everywhere in your application”?
Simon,
EOF is single threaded and blocking at the database layer (even with concurrent request handling enabled). You can spawn new ObjectStoreCoordinators to create multiple concurrent channels to the database, but in doing so you eviscerate the caching and optimistic locking capabilities of EOF (and need to fetch constantly to ensure data freshness). I’m currently working on a legacy project where the original developer thought this was necessary. The resulting architecture is not pretty and I am not enjoying myself at all 🙂 Hence my recommendation.
Do you have any link or documentation where I could read more about this issue? Have Apple made any comments?
Yup, EOF concurrency is fully documented here. Let me be clear, I don’t have an issue with the current EOF architecture. It works great for me. The caching mechanism is very strong, and if I have a query that takes too long, I try to fix that in the DB. Spawning new application instances to reduce the number of concurrent users is an easy solution as well, and much easier than trying to fight the architecture of EOF.
Wouldn’t it be better that the framework let the database handle concurrency and use less cache?
From what I understand, WO 5.2 was supposed to have addressed this issue of concurrency by finally making the offending portions of EOF multithreaded.
In my own case, where I am stuck using 5.1.3, I created a framework that combines several “solutions” that I found on the internet to accomplish the same thing.
First I created a pool of ObjectStoreCoordinators. Each new session chooses a coordinator from the pool in turn. By lowering or increasing the number of coordinators in the pool I can tune the application to find the best memory to performance point.
To solve the issue of synchronization between the coordinators (without having to constantly refresh) I borrowed from the idea of the EOF Change Notification Framework by David Neumann. When EOs in one coordinator change then the other coordinators are notified and they update their snapshots with the new information. My code is actually a lot more simple for this since I don’t have to notify coordinators in other running applications (no need to make mock HTTP requests, etc.).