Gyorgy Bozoki wrote:
> 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.
are you seriously suggesting that data which is used in a NEW system
should be stored in flat file ascii crap?
THese files should only be used to get data from system A to system B
in a format both systems can understand. Once the data
is transported, the files should be destroyed. And also: if this transportation
is required a lot, one should consider writing a
service on system A using A's db directly offering a service to B to do work
for B on the db of A instead.
> 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.
Ok, but there's _no_ reason to keep data in flat ascii files. NONE. Use
a database. This thus implies a one-way read action
from the ascii goo into a new format stored in a persistent storage where you
can work with in your software.
> 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!
sure, but the converter should be used to convert the data from system
A's format to system B's format so code in B can use
the data inside B. This should be done once. So any BO doesn't access any
converter, as that's not what it works with. Any BO in B
works with the data in B, which is inserted into B using another route, another
process, namely the one-way flat file ascii drivel
-> database of B.
I got the feeling you wanted to read the ascii data every time the BO
is used.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
