> No, of course I didn't suggest to use text files for storing the data. I
> meant to use the converter object as a bridge: either use it every time (if
> the legacy data still changes) when the new system needs data or simply
> import the whole old set of data into the new database in one shot if it
> doesn't change anymore. The latter of course is the better case,b ecause
> then the converter object is a throw-away, it doesn't have to complicate the
> actual application.
>
> Text files in new systems should only be used as input or output, not
> general storage.
Thanks Gyorgy, for clearing that up. I agree with your remarks above :)
FB
>
> Gyorgy Bozoki
>
> > -----Original Message-----
> > From: Discussion of advanced .NET topics.
> > [mailto:[EMAIL PROTECTED] On Behalf Of Frans Bouma
> > Sent: Thursday, November 16, 2006 10:11
> > To: [email protected]
> > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net?
> >
> > 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.
> >
> > 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
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
