> ORM was useful as a _developer_ productivity tool - provided a project fully > invests in being designed to take advantage of it, and the project's aims > lend themselves to doing this, using an ORM instead of handrolling queries > gives you massive efficiency benefits; you get db independence which is very > important when selling stuff to clients who all have their own demands about > what DB you run on, and your code in general is, at least in theory, a lot > more 'java like', eliminating the need for all your programmers to also be > SQL gurus. Fantastic. Massive savings.
Yeah it sounds great in theory, until you hit what I call the "projection problem". In practice, anything but the simplest of CRUD applications, needs to project slightly different views of the database regardless of whichever unified class model you've come up with in your shared backend. ORM's in Java simply can't scale because of this (and lazy fetch only get's you so far), as you have no way to put together an expression tree that maps to raw SQL and lets the database optimizer do its magic. > The same goes for DI. DI is just one kind of IoC, and I have truly never understood the need to depend on external wiring-up containers which renders the code impossibly to statically analyse or read, without consulting annotations and XML and construct mental models from it. Just use an SPI pattern and let the build tools solve this "problem" through the runtime-environment/class-path. If you sense a theme here, yes, I'm weary of framework usage without factoring in drawbacks. These are dependencies which does add a cost. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
