I feel stupid making a business object

[jehugaleahsa]

Hello:

Do any of you ever feel stupid for creating a business object? I have
this business object that is pretty much just a wrapper around
whatever the database returns. The properties just have backing fields
of the same type.

The class does nothing special. It is essentially a storage location
for what gets returned by the database.

Worse than that, I usually use the BO directly, immediately using it
in an insert or update. Most of the processing involved is in creating
this BO.

Why am I creating a business object when the data is in the result
set? What is being gained? A little structure?

My biggest problem is that my current project involves pulling data
out of the database from one table, doing just enough modification
that an insert-select would be impractical, and then sending it to
another table. The process is not complicated. I just wish I knew a
way to make it less bulky, get the benefits of working with a business
object and have code that I can read.

How do I keep the data and the logic from mingling too much? I am out
of ideas.

 

[jehugaleahsa]

I also processing database records one at a time. There is no need to
keep data around for more than one insert or update.

 

[.\\\\axxx]

If YOU don't know why you're doing it - then don't do it!
Without knowing more details about what you are programming, and how
the business object is created etc. it's difficult to judge - but
there's no law to say you HAVE to create a business object to be
populated from the DB - fro what you describe, I would think you could
use a dataset directly - manipulate thedata in the rows, then use it
to insert into the new table. Nothing intrinsically wrong in that, is
there?
Of course, if these business objects are to be reused elsewhere, it's
nice to have the logic 'self-contained' - and it is, after all,
business logic. Your 'original' class could, for example, contain
methods to return an object of your 'new' class - so the conversion
logic is contained within a single class - that 'knows' how to convert
itself.

 

[Marc Gravell]

For comparison, you might want to look at other serialization
technologies such as NHibernate or LINQ [LINQ-to-SQL, ADO.NET Entity
Framework, etc]; these are much more object (class) oriented, so you
get the benefit of improved structure and clarity but without the
overhead of any duplication.

Personally I've never been a fan of DataTable and the associated
classes, but I'm /very/ interested in Entity Framework.

Marc

 

[jehugaleahsa]

If YOU don't know why you're doing it - then don't do it!

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.

Without knowing more details about what you are programming, and how
the business object is created etc. it's difficult to judge - but
there's no law to say you HAVE to create a business object to be
populated from the DB - fro what you describe, I would think you could
use a dataset directly - manipulate thedata in the rows, then use it
to insert into the new table. Nothing intrinsically wrong in that, is
there?

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.

Of course, if these business objects are to be reused elsewhere, it's
nice to have the logic 'self-contained' - and it is, after all,
business logic. Your 'original' class could, for example, contain
methods to return an object of your 'new' class - so the conversion
logic is contained within a single class - that 'knows' how to convert
itself.

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.

 

[Mufaka]

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.

DataReader is read-only, forward-only. So, you have to put the data
somewhere to manipulate it.

So you can pick variables, value objects/entities/business objects, or
use something built in like a DataTable.

The latter seems like the best option based on how you are using the
data. You can populate that from your DataReader or change how your are
retrieving your data.

 

[Registered User]

Hello:

Do any of you ever feel stupid for creating a business object? I have
this business object that is pretty much just a wrapper around
whatever the database returns. The properties just have backing fields
of the same type.

The class does nothing special. It is essentially a storage location
for what gets returned by the database.

Everything needs to be somewhere. Wrapping data with simple object is
nothing unusual.

Worse than that, I usually use the BO directly, immediately using it
in an insert or update. Most of the processing involved is in creating
this BO.

Is this type really a business object? Although this type may enforce
some business rules regarding the data, I see it as a layer of
indirection between the data source and the data consumer. More of a
data adapter than a business object.

Why am I creating a business object when the data is in the result
set? What is being gained? A little structure?

My biggest problem is that my current project involves pulling data
out of the database from one table, doing just enough modification
that an insert-select would be impractical, and then sending it to
another table. The process is not complicated. I just wish I knew a
way to make it less bulky, get the benefits of working with a business
object and have code that I can read.

How do I keep the data and the logic from mingling too much? I am out
of ideas.

Use the type encapsulate whatever logic is needed to transform the
data into a format suitable for the consumer. Pass the data container
(row, node...) as a c'tor argument and let the object do what needs to
be done. There should be no need for code that manipulates the object
that manipulates the data, keep it all internal to the object. The
consumer can then use object properties and methods to access the
data.

regards
A.G.

 

[jehugaleahsa]

Here is what I decided to do:

Since I had to pull the data from the query out, I created a simple
class for holding all the values.

I wrote one method that had the query command and a loop to go over
each row returned. I passed the IDataReader as an IDataRecord to a
method that had the job of creating an instance of my data class and
populating internal fields. Only the factory class and the data class
can see these fields. That let me get away from properties. Then I put
a single public method inside the data class called Insert. When you
call it, it does any logic up-front and then generates an command
object, setting the parameters.

To anyone outside these classes, the code looks like:

foreach (MyDataClass mdc in DataFactory.GetDataClasses())
{
mdc.Insert();
}

Since no one but the data class needs to know what is in it, that
leaves the interface simple. However, the code inside the Insert
method is still fairly ugly.

With this I have separated the code that queries, creates the data
class and the logic to prepare the data for insertion. I hope it is
good enough.

Thanks for everyone's thoughts!

 

[RobinS]

If you are displaying the data on a form, you can data bind your business
object to the controls on the screen and fill them automatically.

For more info on programming with objects, check out Deborah Kurata's book,
"Doing Objects in VB2005". It's in VB, but it's not hard to translate it to
C#.

RobinS.
GoldMail, Inc.

 

[Christopher Van Kirk]

Hello:

Do any of you ever feel stupid for creating a business object? I have
this business object that is pretty much just a wrapper around
whatever the database returns. The properties just have backing fields
of the same type.

The class does nothing special. It is essentially a storage location
for what gets returned by the database.

Worse than that, I usually use the BO directly, immediately using it
in an insert or update. Most of the processing involved is in creating
this BO.

Why am I creating a business object when the data is in the result
set? What is being gained? A little structure?

My biggest problem is that my current project involves pulling data
out of the database from one table, doing just enough modification
that an insert-select would be impractical, and then sending it to
another table. The process is not complicated. I just wish I knew a
way to make it less bulky, get the benefits of working with a business
object and have code that I can read.

How do I keep the data and the logic from mingling too much? I am out
of ideas.

Separation of concerns is your answer here. The intended effect of
separating data i/o from business logic is to enable you to be more
independent and portable in how you actually store and retrieve the
data. Today you might be satisfied with a particular flavor of SQL
database, but tomorrow you may decide what you really need is a web
service instead. Wrapping up your answer like this gives you the
ability to swap out the underlying I/O without having to refactor your
entire system.

 

[Jon Skeet [C# MVP]]

Separation of concerns is your answer here. The intended effect of
separating data i/o from business logic is to enable you to be more
independent and portable in how you actually store and retrieve the
data. Today you might be satisfied with a particular flavor of SQL
database, but tomorrow you may decide what you really need is a web
service instead. Wrapping up your answer like this gives you the
ability to swap out the underlying I/O without having to refactor your
entire system.

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.