Data Access return types

  • Thread starter Thread starter Kevin C
  • Start date Start date
K

Kevin C

What is the recommended practice for returning data from your data access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for creating the
business entities?

I have seen people say that the DAC should never return business entities
and always return datasets.
 
Kevin,

I would agree. I think that the business entities should be responsible
for constituting themselves based on the information that they get from the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the DAC
and the business layer as well.

Hope this helps.
 
If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the DAC
and the business layer as well.

Not necessarily true. I have a DAL library
(http://dotnetdallib.sourceforge.net) that allows you to create and change
your business entities as you see fit. The DAL library uses attributes in
the business entities to figure out how to map the tables to the objects and
performs the actual population of the objects.

Pete
--
http://www.petedavis.net
Nicholas Paldino said:
Kevin,

I would agree. I think that the business entities should be responsible
for constituting themselves based on the information that they get from the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the DAC
and the business layer as well.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin C said:
What is the recommended practice for returning data from your data access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for creating the
business entities?

I have seen people say that the DAC should never return business entities
and always return datasets.
 
Absolutely.

Pete

--
http://www.petedavis.net
Nicholas Paldino said:
Pete,

This is definitely an option. The statement I made was if the OP wanted
to use something other than an interface or a base type which all types
implement or derive from (which is the impression I got).

If all business entities derive from a base class, or they all implement
an interface which allows the internals to be set by the DAC, then this
would be fine.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Pete Davis said:
If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change
the
DAC
and the business layer as well.

Not necessarily true. I have a DAL library
(http://dotnetdallib.sourceforge.net) that allows you to create and change
your business entities as you see fit. The DAL library uses attributes in
the business entities to figure out how to map the tables to the objects and
performs the actual population of the objects.

Pete
--
http://www.petedavis.net
message news:[email protected]...
Kevin,

I would agree. I think that the business entities should be responsible
for constituting themselves based on the information that they get
from
the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change
the
DAC
and the business layer as well.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What is the recommended practice for returning data from your data access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for creating
the
business entities?

I have seen people say that the DAC should never return business entities
and always return datasets.
 
Pete,

This is definitely an option. The statement I made was if the OP wanted
to use something other than an interface or a base type which all types
implement or derive from (which is the impression I got).

If all business entities derive from a base class, or they all implement
an interface which allows the internals to be set by the DAC, then this
would be fine.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Pete Davis said:
If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the DAC
and the business layer as well.

Not necessarily true. I have a DAL library
(http://dotnetdallib.sourceforge.net) that allows you to create and change
your business entities as you see fit. The DAL library uses attributes in
the business entities to figure out how to map the tables to the objects and
performs the actual population of the objects.

Pete
--
http://www.petedavis.net
message news:[email protected]...
Kevin,

I would agree. I think that the business entities should be responsible
for constituting themselves based on the information that they get from the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the DAC
and the business layer as well.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin C said:
What is the recommended practice for returning data from your data access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for
creating
the
business entities?

I have seen people say that the DAC should never return business entities
and always return datasets.
 
Yes Nicholas,
I was getting more after "who" should be responsible for building the
business entities: the DAL or Business Components?


Nicholas Paldino said:
Pete,

This is definitely an option. The statement I made was if the OP wanted
to use something other than an interface or a base type which all types
implement or derive from (which is the impression I got).

If all business entities derive from a base class, or they all implement
an interface which allows the internals to be set by the DAC, then this
would be fine.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Pete Davis said:
If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change
the
DAC
and the business layer as well.

Not necessarily true. I have a DAL library
(http://dotnetdallib.sourceforge.net) that allows you to create and change
your business entities as you see fit. The DAL library uses attributes in
the business entities to figure out how to map the tables to the objects and
performs the actual population of the objects.

Pete
--
http://www.petedavis.net
message news:[email protected]...
Kevin,

I would agree. I think that the business entities should be responsible
for constituting themselves based on the information that they get
from
the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change
the
DAC
and the business layer as well.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What is the recommended practice for returning data from your data access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for creating
the
business entities?

I have seen people say that the DAC should never return business entities
and always return datasets.
 
Kevin,

Well, ultimately, that's up to you and what will work best for your
solution in terms of maintainability, ease-of-use, ease-of-development, etc,
etc. You won't be struck by lightning (although in some cases, I wish
people were when they do certain things) if you choose one over the other.

At worst, it won't work.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Kevin C said:
Yes Nicholas,
I was getting more after "who" should be responsible for building the
business entities: the DAL or Business Components?


message news:[email protected]...
Pete,

This is definitely an option. The statement I made was if the OP wanted
to use something other than an interface or a base type which all types
implement or derive from (which is the impression I got).

If all business entities derive from a base class, or they all implement
an interface which allows the internals to be set by the DAC, then this
would be fine.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Pete Davis said:
If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the
DAC
and the business layer as well.

Not necessarily true. I have a DAL library
(http://dotnetdallib.sourceforge.net) that allows you to create and change
your business entities as you see fit. The DAL library uses attributes in
the business entities to figure out how to map the tables to the
objects
and
performs the actual population of the objects.

Pete
wrote
in
message Kevin,

I would agree. I think that the business entities should be
responsible
for constituting themselves based on the information that they get from
the
data layer. If you have the DAC return business entities, then when the
business entity changes (as it always does), you will have to change the
DAC
and the business layer as well.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What is the recommended practice for returning data from your data
access
components when you have already made the decision to go with custom
entities? Should the DAC return datasets or be responsible for creating
the
business entities?

I have seen people say that the DAC should never return business
entities
and always return datasets.
 
Back
Top