Jon, Please see my answer inline.
HTH, Gyorgy Bozoki > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Jon > Rothlander > Sent: Thursday, November 16, 2006 11:41 > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > The others suggested not taking on the problem > or changing languages. Here's another example... > > DATE Start(1) Length(8) > YEAR Start(1) Length(4) > MONTH Start(5) Length(2) > DAY Start(7) Length(2) > > Looking at this one system that I can port about 90% or more > to .Net as of today. This sort of code exists in over 1,000 > programs that contain anywhere from 500 to 5,000 or more > lines of code. It does exist in utility programs that are > called, but some sort of code like this exists in nearly 100% > of the programs. Most of the programs have 3 or 4 data > structures like this set up. For this, you can simply use a DateTime field inside your business object. Keep in mind that your business object does not talk to the legacy system directly and does not read/write any legacy data directly. It should not do any of these, because it means tieing it to the legacy system, which is something you want to avoid. In your new system you want to be as free of the old system as possible, but still work with it. So if the legacy system needs to pass a date like this to you, it should invoke a converter object in your new system that knows how to take a date in this format. That converter object will take the data, parse it and make sure it's fine and only then invoke the actual business object to take the data. The business object only sees a .Net DateTime data type, never the old legacy date. When the new system needs to pass a date in your COBOL format to the legacy system, the business object should write it's .Net DateTime field into the converter object (the same as above or another one) and that converter object will format the date in such a way that the result conforms to your COBOL application's expectations. Then the converter object can produce an output ascii file or call the legacy system in some way. Notice, that data in the old COBOL system becomes simply input and output of the new system. Now, as Frans Bouma pointed it out, depending on your old data, you have two choices for the converter object. If your old, legacy data is still updated daily, you need to use a converter object every time when you want to talk to the legacy application from your new system. However, if your old data is mostly constant, you can simply import you entire set of old data into your new system's database in one shot and then you can throw away the converter. The latter is a better and easier scenario, since having the data in a proper database makes it immensely simpler to work with it and your .Net application becomes a lot simpler. So, when the old legacy code tries to puch FullName, don't let the FullName into your new system as a single property. Give the old legacy system access only to the converter layer of your new system, that knows how to parse the FullName into 2 distinct properties: FirstName and LastName. > The problem here is that all of the code is pushing to > FullName (DATE in the above sample). That's really kind of > the whole point these structures are used in the legacy > systems. So all of that code would have to be rewritten if > we made the FullName/Date readyonly. The whole goal here is > to find a way to get all of the code working without having > to rewrite it all. Once it's functional, we can go back and > make these changes as we have time and as we go forward. We > just want the application to work first, then we can > performance tune and remove issues like this. > > >>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. > > Ok. I see what you are saying here. What you have a problem > with is pushing to fullname and have it divided into the > other properties. Is that the main concern here? Well, that > and the padding. When you use a converter object (or a conversion layer), this becomes a non-issue: all data coming from the legacy system passes through the converter and that rips out all padding that's there in the old data. Instead of FullName, the new system simply sees a distinct FirstName and LastName, no padding. This works the other way around, too: all data going out from the new system towards the legacy system are going to be merged together and properly padded. In this case, your legacy system will never receive a FirstName or a LastName property: it'll only get a padded FullName property. So the conversion layer hides internal details from the "other side": it hides legacy details from the new system and hides new details from the legacy system. Both systems work with data in a way that's easy and "natural" in that particular system. Don't get me wrong: I'm not trying to imply that you get all this without work. But you should realize that we're talking about work that's not going away in either approach. As I wrote in one of my other emails, doing it right will not be any less work than doing it wrong. There is still a gain, however: if you do it right, your *new* system will be very flexible and relatively easy to maintain. This doesn't affect the old system: that's already a done deal. But you're going to work on your new system for a while, so you might as well do yourself a favor and spare some pain in the future. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
