On Mar 4, 4:48 pm, ".\\\\axxx" <mailma...@gmail.com> wrote:

I do know what I am doing. I have tried two approaches. In one, I
created a business object to represent the results of the query as an
entity. I populated the BO with the results of the SQL and then used
the BO to populate the parameters of my insert command. However, here,
I felt like I was glorifying the data; it was just data and it didn't
really play a role in my application. Sure, it did that small thing,
but it was specific to one method and unusable everywhere else.

Then I tried just creating temporary variables to hold the results of
the DataReader; I have to pull some fields off, since I need to edit
their values. Anyway, this reduced the need for all the overhead of a
business object, but then I had all these variables thrown all over
the place. Sure, my business object's fields were used in the same
places, but the relationship was easier to see.

I think half of my problem is that the data I pull off isn't really
"conceptually" one object. It is just data. It is hard to create an
object when the data isn't easily relatable. Essentually, I am just
moving data. I would think something simple and script-like would get
the job done, but it just doesn't seem altogether there. I think I am
out of options.

I can separate parts out, which makes my method smaller. However, the
code is still not very structured . . . it is just how it looks.

There isn't a dataset. I would be working with an DataReader. Here, I
am forced to take the data out so I can manipulate it. So I am back to
where I was before: one or the other.

That is another point. They aren't used anywhere else, except in this
one method that does one thing.

I have thought about a class that simply mutates its own fields by
looking into itself. However, at the beginning of the process I
typically have more data than I do at the end. So, half my properties
are used only to generate the others. Additionally, moving the logic
that does the code from top to bottom into properties that do a
specific action for a specific field would require a lot of careful
refactoring. I will probably also mean that code will be duplicated.
Since one piece of data may modify the value of multiple others, I
would have to duplicate this code for each of the modified fields.
Then I would have potentially more, uncoupled, duplicated code. It
sounds cool, but it has many negatives.

I could move everything inside a "Insert" method that does the
"conversion" for me, but here I am essentially separating the insert
from the select, essentially putting a bunch of temporaries (the
business object properties) inside the insert portion.

1) I need a place to store my data
2) I need to use some data to manipulate the rest
3) I need to pass the data into the parameters.
4) I may need to follow this pattern for many more methods of a
similar taste.

There's a very important point in Christopher's post vs jehugaleahsa's
(the one Christopher was replying to).

Christopher talks about keeping data *I/O* separate from the logic.
jehugaleahsa talks about keeping the *data* separate from the logic.

Keeping the data and logic *together* is object-oriented, whereas
keeping the persistence mechanism separate is a different matter.