Design Question About Passing Entity Objects

[Arsen Vladimirskiy]

Hello,

If I have a few simple classes to represent Entities such as Customers and
Orders.

What is the proper way to pass information to the Data Access Layer?

1) Pass the actual ENTITY to the Data Access Layer method
-or-
2) Pass some kind of a unique id to the Data Access Layer method

For example, how should the DAL.FindCustomer method be implemented:

1) public static Customer FindCustomer(Customer customer);
-or-
2) public static Customer FindCustomer(int customerID);

If I need to find a customer either by an ID or by the username, what is the
proper way:

1) public static Customer FindCustomer(Customer customer); // and the method
will look at the filled-in properties of Customer and determine what to
search by
-or-
2) public static Customer FindCustomerByID(int customerID); and public
static Customer FindCustomerByUsername(string username);

I understand that passing the ENTITY is more expensive than passing a single
unique key. However, does the abstraction that is gained by passing the
whole entity justify doing it this way?

If I need to add an order for a Customer. I could do it the following two
ways:

1) public static int InsertOrder(Customer customer, Order order)
-or-
2) public static int InsertOrder(int customerID, Order order)

WHICH IS BETTER?

Thank you in advance!
-AV

 

[David Browne]

Hello,

If I have a few simple classes to represent Entities such as Customers and
Orders.

What is the proper way to pass information to the Data Access Layer?

1) Pass the actual ENTITY to the Data Access Layer method
-or-
2) Pass some kind of a unique id to the Data Access Layer method

For example, how should the DAL.FindCustomer method be implemented:

1) public static Customer FindCustomer(Customer customer);
-or-

If you already have the Customer object, what would FindCustomer do?

.. . .
I understand that passing the ENTITY is more expensive than passing a single
unique key.

Nope. No more or less expensive. You are just passing a reference to the
entity.

However, does the abstraction that is gained by passing the .. . .

1) public static int InsertOrder(Customer customer, Order order)

Definity this one. You should pass your entity objects except where you are
loading them from the database, of course.

David

 

[Arsen Vladimirskiy]

Hi David,

The public static Customer FindCustomer(Custoemr customer) is used to look
for the FULL customer Entity using a partially filled-in entity that is
passed to it.

So for example, I could pass the customer.CustomerID and FindCustomer would
return the FULL Customer entity with all the fields filled in.

In a sense, the FindCustomer is the one that loads the customer from the
database into an ENTITY object. Should I make it FindCustomerByID(int
customerID) instead?

Thanks,
AV

 

[David Browne]

Hi David,

The public static Customer FindCustomer(Custoemr customer) is used to look
for the FULL customer Entity using a partially filled-in entity that is
passed to it.

So for example, I could pass the customer.CustomerID and FindCustomer would
return the FULL Customer entity with all the fields filled in.

In a sense, the FindCustomer is the one that loads the customer from the
database into an ENTITY object. Should I make it FindCustomerByID(int
customerID) instead?

Yes. I think partially loaded entity objects are a needless complication.

David

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Arsen,

It depend of the way you ( or your team) design the system and the system
requeriments tiself.

I will give you an example of how I designed the system I'm working right
now.
I have classes that represent the entities of my business, each of these
classes export a number of properties, and a method Save() , inside this
method I create a SqlCommand with the SP and its parameters , then I call
the DAL class that simply execute the command,
The good think I see in develop like this is that the logic to "save" an
entity is inside that entity. relying in an external object to really
execute the command in the database.

This would not work if for example the backend could be one of several DB
engines. As in my particular case the backend is SQL Server I can safely
pass a SqlCommand.


Hope this help,

 

[Darin]

Actually, you could have your design work if you passed a IDbCommand object
instead. I do something similiar to what you do and my data helper classes
take the IDBCommand which will allow different backends. Just a FYI.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Darin,

No really, as the Command is buid inside the entity it would need to know
what kind of backend it's in use to build the correct one.

Cheers,

 

[Gilles Muys]

Ignacio,

I disagree with you. My object objects do not care which back end is
being used: it could be SQL Server, Access, Oracle, an XML file, or some
other type of data store that I do choose to support in my object
framework. My business and dataobjects manipulate only IDataParameters,
IDbCommands, IDbConnections, and so on. The use of polymorphism in this
context is highly recommended, especially since .NET is already doing
all the hard work for you. ;-)

Gilles

 

[Rob Teixeira [MVP]]

While this is MOSTLY true, you will find that some providers/drivers don't
support certain features, don't use certain features with the same results,
or perform poorly with certain generic operations. The devil's in the
details
While I agree that polymorphism is outstanding for dealing with
database-agnostic code, I recommend doing something a little more
high-level, and making the data layer itself more specific. For example,
plug-in interfaces for data access modules, which then internally do
whatever optimized job they have to talk to specific databases. It might
seem a bit more complicated at the outset, but it's better than hitting some
unkown database driver bug/limitation and realizing you have to write
specific workaround code anyway, only this way, the structure is more
formalized.

But that's just my opinion. Feel free to disagree, as Dennis Miller would
say

-Rob Teixeira [MVP]

 

[Tim]

Ignacio Machin,

Is it your view, that custom classes are the best design to represent
business entities? I am wrestling with the idea of either using custom
classes or typed datasets. Also, do u pass your business entities around or
do you make their properties static? For instance, in might need a business
entity of data (user input/db values) for a business object that does some
calculations and then you might need that same business entity for a report.

Thanks

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Tim,

IT all depend of your application and what you intend to do with it. If you
have a small application with just a couple of entities and you know for
sure that they will be used by one application then it's time saving using
dataset, but if you are ( as in my case ) developing an application with
around 20 entities that will have more than one interface ( web and PocketPC
application ) then is better to represent these entities as classes. With
custom classes you encapsule the logic inside the class, for example, it;s
easier to say Customer.Save() than build the Command to update the
datatable. in the latter escenario your application needs more knowledge of
how the business logic works. The drawback of this is that you usually end
with an additional DLL ( with the business classes ) that needs to be
maintained and with a number of classes to whom you will need to have common
functionality ( strong typed collections, filtering, etc ) this increase the
complexity of the solution as well as the time needed to develop it.


What you mean with static properties? an entity of data is a instance of a
class. there is usually no static properties involved.
Now what you could use for example is a static repository for your data.
let's explain this with an example. If you have a Customer class that
represent a customer it may have a static property CustomerList that return
all the customers as a strong typed collection, so you could say:
Customer.CustomerList
to get all the customer on the system.

Beware that this may have some implication with multithreading.


Hope this help,

 

[Tim]

Thanks for the post. When I meant by static is the business entities being
implemented as a singleton. I rather not have to pass each business entity
to all my BO. However, I am struggling with this idea because my BO will
need to know which entities it needs.

Thanks