1

I recently had a question regarding String Object with fixed length C# . (Please read this question first)

Some of the answers, which were given, pointed out that my design might be flawed.

Since the last question was about Strings with a fixed length this one is about the underlying principle. This question might be a little bit long so pleas bear with me.

Requirements:

I have a plain textfile with values in it with a specified fixed length. The standard for this textfiles is from the 90's. I have to create such a file.

  1. A File may contain 1-60 Rows.
  2. There are 10 different types of Rows.
  3. A Row has between 10-40 values.

A Row is specified like this:

Specs Table

Back in the 90's there was an application which created those files placed it on a Server and the server then read the File and did something with it like writing it to the database or informing somebody that something went wrong etc.

enter image description here

This application isn't usable anymore due to recent legal changes.

Suggested design

The new Application that is in its place doesn't provide any data in the form of an export but it has a database with the values inside. I have the responsibility to write a converter. So I have to get the data and write an exported text file. The Data is only send and never received !

enter image description here

Question

Since a A DTO's only purpose is to transfer state, and should have no behavior(POCO vs DTO) Is there something like a "Data Conversion Object" which has the purpose of converting data which is transfered ? Is there a design pattern which is applicable ?

Community
  • 1
  • 1
Bongo
  • 2,933
  • 5
  • 36
  • 67
  • There is a pattern for doing such data conversion operations: [Extract Transform Load (ETL)](https://en.wikipedia.org/wiki/Extract,_transform,_load). Anything else, and you would be overthinking it. –  May 13 '16 at 10:10
  • You can still have DTOs with behavior. I wouldn't try and lock out to a particular methodologies or patterns, just do what works then refine as a matter of course – Callum Linington May 13 '16 at 10:12
  • Looks like a big thing, but the problem is really small one and you are over-complicating it. All you need during export is to validate data whenever they can be exported or not. Nothing else. No additional abstractions. Automatic validation using some attributes is ok, but "data conversion object"? It's just a method which receive one type and produces another, sure, put it into another class (it doesn't make sense to couple types by having this method inside one of them), but that's all. Another question is whenever it make sense to start using special type to hold basic type... – Sinatr May 13 '16 at 11:18
  • @Sinatr in fact my solution seems very simple. You fill an object with a value from a Database this is then checked for validity and is stretched/filled up with spaces where needed. The rows can't be malformated because a row is a class with defined fields and the document consists of rows. – Bongo May 13 '16 at 11:29
  • 2
    This is interesting... You say the source is a database. Without assuming what kind of database system it is, it is likely that it will have a query language of some kind that will allow you to retrieve only the data that you need for export, that is, the data with the strings of correct length. Another thing to consider is that speed is key in ETL processes, so you do not want to have complicated logic applied to the source data if you can avoid it. –  May 13 '16 at 13:12
  • @jeyoung valid point, otherwise I might not be in charge of the data that is pushed inside of my object. Its a public object so I should check i guess – Bongo May 13 '16 at 13:15

1 Answers1

0

I recently designed a solution for a similar problem, though my solution was in SAS language, which is not Object-Oriented. But, to me it seems that the problem is pretty much the same. Now, lets dissect the problem:

The problem:

  1. There are some plain text files.
  2. These files have specification, about the layout, fields, types etc.
  3. These files need to be converted to some other format.

Solution (Objected-Oriented): I would define three classes, PlainTextFile, Specification, Output, and a Reader Class.

Specification: Contractor takes an specification (probably it is stored in a file or so), and parses that into an Specification object.

PlainTextFile: This can be handle to a text file, or a wrapper around the handle if some other feature is added to it. I prefer the second option.

Output: This is the output you would like to produce.

Reader: It takes two inputs, PlainTextFile and Specification. Uses Specification to read and parse the PlainTextFile and write the output in the Output object/format.

Now, the output can be the final step or not. I suggest, that the Reader do only this much. It you want to write the output to a database, or send it somewhere, create another class to do this.

Remember, I don't know what the name of this pattern. Actually, I don't think that matter much. For me, this method solved a problem that existed in the company for a decade and it integrated two of the most used systems there.

Nazar Merza
  • 3,365
  • 1
  • 19
  • 19