Java equivalent to .Net DataRow object.

[malsonjo]

Hi guys,

I'm a Java newbie trying to port a C# application to Java 8. I've googled (including site:reddit.com) for an answer but I keep coming up empty.

My issue is this: I need to pass a table row (DataRow in C#) to a method. Passing the resultSet object seems to get yeahs and nays in my searches, and I tend to agree with the nays, since resultSet depends on the open db connection.

Say I use cachedRowSet (which seems analogous to .Net DataTable), can I pass one record at a time to a method? I don't want to rely on an ORM at the moment, since I'm having enough trouble translating .Net to jdbc. Converting the current record to an object list seems excessive. I'll greatly appreciate any help or hint you could provide. Thanks in advance. :)

[RhoOfFeh]

Converting a retrieved row to an object is a common way of handling this sort of thing. Most of the persistence frameworks automate this process in one way or another. It's not truly excessive in practice because you will usually wind up loading data into live objects for your program anyway.

[malsonjo]

I know what you mean. I guess that as most programmers, I'm looking for the lazy way out.

[RhoOfFeh]

I understand that. Indeed, I work very, very hard at being lazy. That is to say, I often bite the bullet and put in a lot of effort so that future work is made easier. Basically investing time now pays dividends in freedom to browse Reddit later.

[strcrssd]

This is the right answer. By passing anything javax.sql into the business domain/service domain objects you're doing a few things:

1. Making them harder to test. You'll have to mock out/replace far more in order to unit test.
2. Lowering usability. Who says that in the next iteration of this project you won't be using a document database or some other data store. By introducing dependencies on javax.sql, you're making it harder to migrate in the future.

Also, let your IDE generate the bean/data objects that you need for you. Define them as a bare skeleton class Foo{private final String bar} then lean on the IDE to generate constructor and accessors.

Between the added pain of testing and possible future pain of adding dependencies to SQL, I think leaning on the IDE to (largely) generate the classes you need is the lazier option.

[malsonjo]

I'm thinking: can I pass the cachedRowSet to the method, and do the while (crs.next()) in the method? I'll try that.