By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,706 Members | 2,030 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,706 IT Pros & Developers. It's quick & easy.

Design Question About Passing Entity Objects

P: n/a
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
Nov 15 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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
Nov 15 '05 #2

P: n/a
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" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@TK2MSFTNGP12.phx.gbl...

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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

Nov 15 '05 #3

P: n/a

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl...
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
Nov 15 '05 #4

P: n/a
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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

Nov 15 '05 #5

P: n/a
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 )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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


Nov 15 '05 #6

P: n/a
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Darin" <none> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl...
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 )" <ignacio.machin AT dot.state.fl.us> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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



Nov 15 '05 #7

P: n/a
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

Ignacio Machin ( .NET/ C# MVP ) wrote:
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,


Nov 15 '05 #8

P: n/a
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]

"Gilles Muys" <gm***@gmsoftware.com> wrote in message
news:ut**************@TK2MSFTNGP09.phx.gbl...
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

Ignacio Machin ( .NET/ C# MVP ) wrote:
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,

Nov 15 '05 #9

P: n/a
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 )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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


Nov 15 '05 #10

P: n/a
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Tim" <none> wrote in message news:OK**************@TK2MSFTNGP11.phx.gbl...
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 )" <ignacio.machin AT dot.state.fl.us> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
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



Nov 15 '05 #11

P: n/a
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

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:ei****************@TK2MSFTNGP09.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Tim" <none> wrote in message news:OK**************@TK2MSFTNGP11.phx.gbl...
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 )" <ignacio.machin AT dot.state.fl.us>

wrote
in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Arsen Vladimirskiy" <ar***@emergency24.com> wrote in message
news:On*************@TK2MSFTNGP11.phx.gbl...
> 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
>
>



Nov 15 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.