Link Details

Excellent stuff the only thing missing was a class to manage a collection of business objects but that 's beyond the scope of the article. It looks like that will be discussed in a later post so no big deal.

... Or just use NHibernate and have persistence and state solved for you immediately.

It isn't unreasonable to be aware of ALL SOLUTIONS. Including using a business object along with a business object collection class or going with a NHibernate solution. It depends on the context. You might *not* always have access to the tools that you want to use on every project or one solution might not even be appropriate. Plus, your client/boss might say no so you need to be able to produce a solution anyway or you could end up on a project that uses an older version of .Net like 1.0. It happens...

That is why i don't ask them (bosses/clients). They don't know what the best choices are.

Gotta love someone kicking it old school. But gotta vote it down because you can get this from Rockford Lhotka's book (VB classic - 11 years ago) and this really isn't the way to go with all that is currently available. Some good ideas.

I agree. This is putting it out there as good advice.

This is _not_ good advice for current projects.

As well, if you want an ActiveRecord style persistence, there's frameworks that do that for you too. We should NOT be writing persistence code in this day and age, and that's exactly what this advocates.

With small caveat of working on very legacy code, but I get the feeling this is being put forth as a valid solution for the intended audience's next project. It's not.

Can i vote this down twice? She is going to use Stored Procs.