Frans, (And everyone else) I'm sorry for not replying sooner - I cannot check my home email from work.
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. 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: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > 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
