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

Passing data around inside applications

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


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

Nov 15 '05 #2

P: n/a
In .net references are passed around, I encountered this problem when I was
using ASP.Net and found that my DataTable was being changed in the Cache
even though I had set it to a totally new object. The only work around I
found for this is that you can do a table.Copy() to copy the whole table to
a new instance.

So to make a long story short you are probably already passing a reference
of the table around. But if you want something a little more elegant you
might want to create a XSL DataSet that holds all your tables in one
location and then have a static class like Global that has an instance of
the class in a static method. Such as:

private static MyDataSet _mydataset = new MyDataSet();
public static MyDataSet MyData { get { _mydataset; } }

then no matter where you use Global.MyData you will always have one stored
location. But watch out if you get a table from it and start modifing the
table in another class it will also happen in the static one, because the
tables are passed by reference. This was done to save memory on large
tables.

"Simon Harvey" <sh856531@microsofts_free_email_service.com> wrote in message
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

Nov 15 '05 #3

P: n/a
Thanks guys :-)

Simon
Nov 15 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.