Talking about what kind of problems the fullname get/set design could cause is really important. I would like to think this one through to see what kind of issues might come up if I take that approach. I certainly do not see all of the problems that others are concerned about.
>>I can hardly imagine a single valid reason (except hardware handlers) >>where you'd need to have a padded in-memory representation of *any* >>read/write property value. Here's a good example. In the legacy systems since each variable has a given length, if you push data into the variable that is greater, it will automatically truncate. So lets say that I wanted to push the current year into a field in a file. So I might do something like.... YEAR = SYSTEMDATE If system date is "20061231", YEAR would equal that as well... right? No, year would equal "2006" because YEAR is defined with a length of 4. In .Net I would have to do something like mid(SystemDate, 1, 4). So now I have literally thousands of lines of code that may or may not do this. So how do you port that into .Net? The first thing I would have to do is take apart code and figure out how it works. Then write the .Net equivalent of the code. That's a lot of work for a large system. We can do this in phase II, but in phase I with just want it to work. Another option is to figure out how to make the YEAR actually only contain a length of 4, which is what we've been discussing in the threads. >>What happens to the data when your client wants >>to change the max length of FirstName? Do you update all your code? Well, you have to update it in any language. How would you get around this in C#? The length of the data is fixed in the database. It's not variable in database. So you have to validate the size of the data in your code anyway. Even in C#. Any validation, max size values, etc. would all have to be updated. Just because the database has changed, doesn't mean that your code will know that the length is now longer. You'd have to update this sort of stuff in any application regardless of the language. Having to update all of the code for a new length in the database field is going to be necessary in any language. That's what they are doing now in the legacy system and it's exactly what they'd have to do in COBOL for .Net. It's also pretty much what they'd have to do in any .Net app. Let's think this through. This is one of the reasons this sort of design is used in the legacy system. What would happen in C#... If someone decided that the max length of given field should be changed from say 10 to 20 and they are working in C#. All of the code that validates the UI for input would also have to be modified if it validates the length. If it does not validate the length, you run the risk of pushing 20 characters into a 10 character field in the database. In a webForm it they have textboxes with 10 as the max size, then they'd have to be changed to a max length of 20. Same goes for winForms. If there is code that validates the length, that code would have to change. Unless I'm missing something here, that would be the case in VB, C#, COBOL, or any other language. What happens in the legacy systems... Now this is different from modern languages, so you have to understand what the legacy systems can do. They can refer to a file directly and at compile time, the data structure is compiled based on the field lengths in the database. That's odd, but that's how it works. So in the legacy system if FirstName was changed from 10 to 20, you'd just recompile. In the legacy code, the data structure can use an external definition, which points to the file and fields themselves. That is not the case in .Net languages. If you change something like this, a lot of code has to be modified. That is not the case in the legacy systems. That's one of the most significant reasons I am having this problem in the first place. What about the new code ported to .Net? There is one advantage to having fixed-length variables in the new code... being that you never have to validate the length. In C# you have to go in and validate the length or set the properties on the controls to limit the input size. In a fixed-length version, you would never have to do that. You might want need to increase the max length values of the UI controls, but that would be the case in any language. So to answer this question, in C# you would have to run around and modify all of your validation code, anything that uses the original length value, all of your control properties with max/min lengths, etc. In a fixed-length version you'd only have to change the length and nothing else. There is no length validation needed because if you push a 20-character string into a 10-character string, it self truncates. So there would be no way to push up more than the number of characters valid in the database definition... in a fixed-length solution. >>What happens if you forget to update just a single place and it makes into >>production? Do you go back to your storage and update all the data to >>match the new length? What kind of client is that where you can do that to >>production data just like that? I don't actually see what problem that would cause. It might truncate data, but that's about it. In a C# version you'd have basically the same issues except that you could run into a problem if you push of 10 characters to a 20 character field in the database. So if you reduced the size, C# or choke on it. A fixed-length version would just automatically truncate the extra characters. If you thinking about the database itself being changed from a field with 10 characters to say 20, well that wouldn't hurt anything here either. If it can contain 20, but we are only using 10, that will not cause any problems in the code. At least none that I can see without testing it. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
