I suggest following article:
Designing Data Tier Components and Passing Data Through Tiers
http://tinyurl.com/2706
Summary: Learn how to best expose your data to Microsoft .NET applications
and how to implement an effective strategy for passing data between the
tiers in a distributed application. (65 printed pages)
Representing Business Entities
Each Data Access Logic Component deals with a specific type of business
entity. For example, the Customer Data Access Logic Component deals with
Customer business entities. There are many different ways to represent
business entities, depending on factors such as the following:
a.. Do you need to bind business entity data to controls in a Microsoft
Windows® form or on an ASP.NET page?
b.. Do you need to perform sorting or searching operations on the business
entity data?
c.. Does your application deal with business entities one at a time, or
does it typically deal with sets of business entities?
d.. Will you deploy your application locally or remotely?
e.. Will the business entity be used by XML Web services?
f.. How important are nonfunctional requirements, such as performance,
scalability, maintainability, and programming convenience?
This document outlines the advantages and disadvantages of the following
implementation options:
a.. XML. You use an XML string or an XML Document Object Model (DOM)
object to represent business entity data. XML is an open and flexible data
representation format that can be used to integrate diverse types of
applications.
b.. DataSet. A DataSet is an in-memory cache of tables, obtained from a
relational database or an XML document. A Data Access Logic Component can
use a DataSet to represent business entity data retrieved from the database,
and you can use the DataSet in your application. For an introduction to
DataSets, see "Introducing ADO.NET" in the .NET Data Access Architecture
Guide.
c.. Typed DataSet. A typed DataSet is a class that inherits from the
ADO.NET DataSet class and provides strongly typed methods, events and
properties to access the tables and columns in a DataSet.
d.. Business Entity Component. This is a custom class to represent each
type of business entity. You define fields to hold the business entity data,
and you define properties to expose this data to the client application. You
define methods to encapsulate simple business logic, making use of the
fields defined in the class. This option does not implement CRUD methods as
pass-through methods to the underlying Data Access Logic Component; the
client application communicates directly with the Data Access Logic
Component to perform CRUD operations.
e.. Business Entity Component with CRUD behaviors. You define a custom
entity class as described previously, and you implement the CRUD methods
that call the underlying Data Access Logic Component associated with this
business entity.
--
Greetz,
Jan
__________________________________
Read my weblog:
http://weblogs.asp.net/jan
"Simon Harvey" <sh856531@microsofts_free_email_service.com> schreef in
bericht news:es*************@TK2MSFTNGP11.phx.gbl...
Hi,
In my application I get lots of different sorts of information from
databases. As such, a lot of information is stored in DataSets and
DataTable objects.
Up until now, I have been passing around chunks of data in
DataTables/DataSets, simply because that was the format that they were in
when the data was taken from the database. Now, I know this maybe a pretty
silly question with a standard "it depends" answer, but I'm going to throw
it open for comments anyway:
Should I keep passing around DataSets and DataTables because it's
convienient or, should I make classes to store the information and pass
instantiations of those classes around instead?
Essentially, I am wondering if it is poor form, to pass information around
in DataSets etc, or whether it doesnt really matter.
Thanks
Simon