ADO.net principles in java

Question

I'm asking on opinion about implementing framework that emulates ado.net in java (data tables, data sets etc). Idea is to avoid writing domain objects since they are, so far, just used to transport data from server to client and back, with no particular business methods inside them. Main goal is to speed up development time. Could i benefit from writing this kind of framework? If it's done before provide link please.

Answer 1

Whether it's ADO.NET or anything else, I've learned that my first step should be to not write any libraries or frameworks. Instead, I get on with the job.

The second time I'm tempted to write a library or framework, I typically think about it for a while, decide not to write it, and get on with the job.

The third time I'm tempted, I'll usually give into the temptation. By that time, I will have written a bunch of code that worked without the library or framework. I will refactor that code (that real, used, tested code). I'll do this iteratively, running my automated unit tests constantly, and writing new tests as necessary. When I'm interrupted in this task (as will happen, since writing frameworks may not be part of my job), I can be certain that I'm leaving running code behind, even though it's only half finished.

When I get back to it, I'll continue refactoring up to a point, remembering that I should get some experience using what I've refactored before going too much further in the direction I think it should go. With real code using it, I won't have to guess which direction to carry the refactoring.

Answer 2

Instead of emulating ADO.NET, I would use an ORM tool such as Hibernate. This way you can have a library that handles all of your SQL and persistence needs on it's own, and you don't have to worry about dealing with a pseudo-table like structure.

I find working with strongly-typed domain objects to be far, far easier and quicker to develop (and test) than working with SQL, resultsets, etc.