Should I have seperate objects for Input and Output, does this pattern have a name?

I am looking for the name of this pattern and to understand the reasons for this design.

I have:

1. Input data(from DB): being put in an object, containing data corresponding to a table row and also the objects of it's foreign keys. Data could come from DB or generated from code for unit testing.

2. A calculator: that analyses, processes and modify this data. I want the input data to stay external to this calculator to be able to unit test it with data generated from code or coming from and XML file instead of a DB.

3. Results data: Then I need to update my database, BUT also those results can be used to validate against expected results in the case of unit testing.

Is this a Separation of Concern Pattern? Is there other known patterns involved here?

Shou开发者_JS百科ld my result object, containing result data, sit in the same object as my input data and null at the begining then updated after the processing, or should the results object be totally independent from the input object, and why please.

I would suggest that your output object be completely independent from your input object. Otherwise your input object has to "know" about the output object. That seems unreasonable because any time you change the output object, you by extension change the input object. Or perhaps you want multiple different output objects. Then the input object needs to know about all of the output objects, or you have an untyped reference (i.e. object in .NET) that you'll need to cast.

The input object is exactly that: it represents the data as its received from your data store or whatever. That input data is passed through some transformation to create an output object of some kind, which might bear very little relation to the input object.

In short, there's no good reason for the input object to have any knowledge of the output object. In fact, the input object shouldn't even be concerned that the output object exists. Giving the input object that knowledge will result in unnecessary coupling, which will make it more difficult to modify your code in the future.

There are many different things in your list which seem to specialized to be part of one single pattern. The cornerstone of you describe seems to be the Repository pattern though.

At a high level, I would refer to this as "ETL", "Extract, Transform and Load". This term is more commonly used in a BI context, but it is the exact same thing conceptually.