- Create
- Read
- Update
- Delete
The single most depressing thing for me in IT is how many applications are really just Mainframe data processing solutions with better screens. Applications for which the word "intelligence" is limited to data validation and there is no actual algorithmic or interactional element to the system beyond just data being lobbed into storage.
Looking at the latest raft of .NET, Ruby, Java and the like CRUD "tools" really is pretty depressing, not so much that they are bad (they aren't) but because people seem to be still insisting on coding this dull and uninteresting crap and looking for yet more ways to "optimise" their code for a task that should be tooled.
Sure there are occasions where you can't tool the CRUD bit because it won't fit into the rest of the application, but are you really sure? Or is it just that it would look a bit "ugly"? Worst of all is the fact that many tools still can't handle "complex" elements like foreign keys and want to do single tables.
CRUD is dull, boring and uninteresting. Can we please just get this stuff tooled and move on to the interesting stuff.
Technorati Tags: SOA, Service Architecture
5 comments:
I suspect that some of the focus on CRUD comes down to the fact that many a developer views their job as always entailing something like:
Write a servlet to generate some HTML which populates a form, which invokes on the app server which creates a message for a queue, which conveys it to a message bean that populates a database.
And they like doing it and they are proud of how well they do it.
What you're asking for is that developers and vendors all step up a level or two and see a much larger picture. Strikes me you're a victim of J2EE's success.....
Dan.
http://www.dancres.org/
I'd actually say that some of the J2EE tools out there (e.g. Oracle, Sun, JBoss et al) are actually pretty reasonable at tooling up the whole CRUD thing. Even to the stage now where they are beginning to do Master/Detail as just a normal thing.
The problem is that people just don't do this because, as you say, they want to use the tools in the box. This isn't limited to J2EE however, you can easily imagine someone in the Jini world doing the "write" via a Javaspace.
Java is to blame however for the massive proliferation of Web "frameworks" which all basically do the same crap and argue about lines of written code as if that should matter.
J2EE isn't the problem, it might even be part of the solution, its the mindset of "tools = bad" that is to blame (IMO).
So, try something different and see how it works for you. Have you ever checked out Naked Objects? Have you looked into using an OODB to back-end an application so the "C" becomes "new" and "RU" become getters and setters? If you want some real fun, try Erlang + Mnesia. I'm playing with Intersystems Cache and their Zen component ... pretty much kicks any *onRails for performance.
I think you've got it spot on. And to some extent the lack of trust in tools I think comes down to how they handle the code they generate, for example, once you make a minor tweak, can it still understand it, or do you have to generate again?
Tooling is close now, and there should be minimal reasons for not using them. JPA takes some good steps. Hopefully we can (almost) wave this goodbye now, though there always be a need to go a tune it sometimes, but that should be a small percentage of cases.
Can you give some examples on tools that one could use, for example on the java platform? IMO the complexity of putting and retrieving object graphs in a relational database is not trivial.
I once co-architected a solution that near fully automated the creation of the DAO layer in a standard architecture with domain objects and all. We used a combination of Hibernate, Middlegen, XDoclet and Velocity scripting. And yes it sure was ugly, and yes it took new developers too long to understand, so yes i pretty much agree that we need tools for this, I just can't recall that I have seen any tool up for it.
Post a Comment