RE: MVC Architecture and transactions

From: DeLong, Eric

Wow, what a statement!

"This I don't buy. If you have people doing "unexpected" things to your
database that could cause transactions to fail, then you have completely
lost control of your database. And at that point, no amount of commitment
control will save you; it will in fact be a false sense of security."

Really Joe, you need to get out in the real world more often... People
doing unexpected things to the database is unfortunately a common
occurance, at least in MY experience.

Eric, I do live in the real world. I've written commercial grade software
for most of my career. I understand that bad environments exist and bad
programs get loose.

My point is that commitment control won't fix this.

These common pressures result in immature code that is
prone to failure. (This is, of course, an issue for management to
address...)

As a side issue, I just don't accept this. This idea that "immature" code
(which is simply a euphemism for badly written and untested code) should
ever be put into production is a cop-out, pure and simple. People who do it
shouldn't be programmers, people who allow it shouldn't be managers. But
that's just MY opinion, and it really has little to do with the argument,
because bad code doesn't get fixed by commitment control!

We've all heard the old mantra "if it ain't broke, then don't fix it"....
As always, the real trouble comes from how you interpret "broke". The
code might be a shambles of two dozen different contractors over the last
ten years, but if it somehow makes its way through its processes without
puking its guts out, then "it ain't broke". Of course, this leads to
"unexpected" things happening to the database.....

And you make my point quite eloquently. Commitment control won't make a bit
of difference in this situation, because the horse done left the barn a LONG
time ago. With CC, completely wrong transactions will be committed
completely, and your database will have been completely updated with
garbage. Yes, it will catch a few weird cases, such as long record locks,
but it won't catch what that "immature" code is doing.

Sorry,

Nothing to be sorry for. You're just making my point for me. There may be
perfectly good reasons to implement CC, but bad programming is not one of
them.

Joe