It *is* about the size, then

Post #195,685

2/20/05 8:56:00 PM

What you describe is actually at least one more layer than the sample code seems to use. First a layer to abstract the db connection. Then a layer to model the db schema. Then a layer to map busines objects to the db schema layer. That makes perfect sense, but neither you nor any of the tutorials explicitly said that.

The objects I tend to work with are already way too large. We're working on refactoring, but we never considered moving the data access completely out of the business objects.

We're currently working on moving all db access out of the display pages and into the business objects. Maybe once that's done we can start moving it to it's own layer. I'm not confident it will be possible though, considering how ugly most of our shemata are.

===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]

Post #195,689

by static

2/20/05 9:32:55 PM

What that achieves.

That approach means you tend to push the crud down closer to the database as you refactor. That's good, in general, because you also tend to rewrite and refactor it away as you push down the layers. Ideally, it all gets refactored away. But in real life, that doesn't happen. What you can probably hope for are ways of isolating the troublesome stuff.

Mind you, figuring out how much knowledge of the database schema to remove from the business objects is difficult.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Post #195,696

by admin

2/20/05 10:04:08 PM

Which is this?

First a layer to abstract the db connection.

I just want to check what you think it is...

Personally, I hate having any knowledge of data access in the business objects. That just leads to all kinds of mess.

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."

Post #195,721

by drewk

2/21/05 2:37:05 AM

The jdbc/connection pooling shtuffs

One note about the data access layer. In an ideal world, all selects are through views and all crud is through stored procedures. (Yes, this assumes you're using a Real Database[tm]. :-/ ) If you've already got that, how important is keeping the data access out of the business objects? The views and stored procs are already abstracting it.

===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]

Post #195,730

by admin

2/21/05 7:01:54 AM

Re: Ideal world

You can't do everything through a view. Sometimes you want your reads coming through stored procedures as well.

Keeping the data access out of the business objects makes unit testing easier.

If you need to serialize your business objects (by putting them in a session, for example) you can't have references to non-serializable objects in them, like database connections and the like.

There's also a lot of management that goes into the data access, like transactions, exceptions, and so on. A good deal of the code associated with data access is managing this stuff, and a data manager lets you do that centrally as opposed to having things scattered across umpty million business objects.

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."

Post #195,753

by drewk

2/21/05 11:35:37 AM

Right, meant "view or procedure"

This does solve our current problem of how to unit test the classes with db access. I'm guessing at some point, though, the data access classes themselves can't really be unit tested.

===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]

Post #195,767

by admin

2/21/05 12:37:42 PM

No, those can be tested as well.

As long as the data is amenable. There are certain things in our system that defy easy testing because of the setup involved.

CRUD stuff is fairly easy to test. Use one data manager method to create the test data and another to remove it. I usually make the data include something that designates it as a unit test record, eg. prepending user names with "utest_". Then in the tear down test method I run a delete where user_id like 'utest_%'.

I usually build the data manager classes first, with unit tests. Then I build a mock data manager to the same interface. As a result, when I get to the controller and JSP portions I don't have to worry about data issues.

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!