Ron,
I'd like to reply to you, even though you didn't ask anything, just
commented on my mail. I know you don't agree with what I wrote, but maybe
this gives more context. Please see it inline.
Gyorgy Bozoki
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of RYoung
Sent: Thursday, November 16, 2006 05:24
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net?
> If you want to have an object with a FirstName and LastName
attribute,
> create and object like that, with two private string
members and two
> public properties. If you then need a FullName property,
create a new
> readonly property and return the concatenation of the two
former; do
> *not* use any padding in your object.
I can agree that an object in the business realm is the
correct way to go.
But what's to say the converter you mention in the next
paragraph can't be an object with property accessors to a
character buffer?
Having such a converter object ties the physical implementation to the
logical meaning of the data. In the physical, legacy storage, the data may
be persisted in a fixed-width file in some way. If my business object then
reads from from the storage, it has to always trim the strings when it
returns them to client code, etc. It can be done, but it's a lot of
unnecessary work, because the logical need tries to keep up with the
physical format. Then, if the phyiscal storage changes (the width
changes),
all code that deals with properly keeping the in-memory string padded will
have to change. I understand that one could use some kind of mapping table
to make sure the code uses the right lengths all the time, but again, it's
a
lot of work for no gain: the code will still only do the very basics of
reading and writing properties.
Jon Rothlander (the OP) has a *logical* need for a FirstName and LastName
property, so that's what he should use. He also has a physical storage
need
for these, to store them in a padded way. The reason for using business
objects in the first place is to decouple these two needs - these are two
distinct layers in the final application.
When one creates an object in the logical layer that internally mimics the
behavior of the physical layer, the distinction is lost and the code
becomes
a lot more complicated, intertwined: now the logical layer is not purely
logical anymore, it has some of the details of the lower physical layer.
If
that layer changes, it'll have an impact on the logical layer. I could
describe this system as 3-tier program: the business object is the
business
layer, the legacy application is the database (it stores and retrieves
data
in some internal way) and the converter object is the "database layer"
that
talks to the business layer and the database.
This is the reason I think a converter object should be used: it provides
very controlled access between the two layers. If one layer changes, the
only things it affects outside of itself are these converter objects. All
the rest of the code will work without changes. That's a huge thing!
One could say that doing it right is just as much extra work - and it's
true. But! This extra work actually gives one flexibility and isolation
from
other parts of the code.
I don't think issues like the valid length of the string are
hardly issues at all, that can be moved out to a
configuration file of sorts. Besides, if it's a legacy system
with existing applications, how a change in the length
affects this application is the least concern.
Yes, you're right, but I was not talking about affecting the legacy
system.
I was talking about changes in the legacy system affecting the new system
that stores in-memory data in the legacy system's format. One could say
this
is an unlikely scenario, but I don't think so. At my work, we have a huge
system that interfaces to several old mainframe applications that are
still
being changed every once in a while. They're also being slowly phased out,
but it'll take at least a year or two when they're finally out. Our
project
is in production for 5 years now, so we saw several changes in the
mainframe
that *could've* had an effect on our system if we stored data in the
mainframe format. (I believe - but not sure - that much of our mainframe
data is in flat, fixed-width files.)
> If you're reworking an old system you might as well do it right.
> Trying to imitate COBOL behavior is certainly wrong in any
> object-oriented language, Java and C++ included.
Isn't it more that C# enables object oriented practices? Sure
the .NET Framework is object oriented, and we design objects
by default, but why does that bind us into striving to being
the best of object oriented programmers, and if the solution
proposed is not OOP in concept and design then it's deemed wrong?
Don't get me wrong, I'm not an OO-fanatic. I don't think that OO should be
used to solve a problem just because that's the only right way to do it.
However, in my experience, it's a lot easier that using old approaches. In
the future, OO may be replaced with something very different and more
efficient, but for past practices, we already know their limitations and
the
amount of work they require. Since there is no way to change the legacy
systems, we have to work with them - but we can do so by weighing the pros
and cons of possible approaches. In this particular case, I think the
COBOL-like approach is waaay more expensive from almost any point of view.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
