Thomas
Regarding DataSets vs. DataReaders:
Take a look at the following article in MSDN:
ms-help://MS.MSDNQTR.2002APR.1033/dndotnet/html/dotnetperftips.htm
Regarding Domain Object Model vs. DataSets:
Our strategy is to limit the use of DataSets/DataReaders to the
persistence layer. We encapsulate all SQL statements in stored
procedures (SQL in business logic code has to be a sackable offence...
;-) ) and then encapsulate these stored procedures in persistence layer
classes. This is a relatively mechanical/tedious thing to do but
simplifies the business logic (which is probably complicated enough as
it is...).
For example:
create procedure Employee_Create @name as nvarchar (50), @dateOfBirth as
datetime
declare @id as uniqueidentifier
select @id = newid()
insert Employee (ID, Name, DateOfBirth) values (@id, @name,
@dateOfBirth)
select @id
is then wrapped in a persistence layer class as follows:
namespace PersistenceLayer
{
public class Employee
{
public static Guid Create(SqlConnection conn, string
name, DateTime dateOfBirth)
{
using (SqlCommand cmd = new
SqlCommand("Employee_Create", conn))
{
cmd.Type = CommandType.StoredProcedure;
cmd.Parameters.Add("@name", name);
cmd.Parameters.Add("@dateOfBirth",
dateOfBirth);
using (SqlDataReader reader =
cmd.ExecuteReader())
{
reader.Read();
return reader.GetGuid(0);
}
}
}
}
}
As you can see, the mapping from the stored proc to C# is very straight
forward. It would not be a difficult task to automate the generation of
these encapsulation classes.
Note that connection management (and also transaction management) is
left up to the business logic.
If a stored procedure returns tabular data then we wrap this in a simple
persistence layer class as well:
create procedure Employee_RetrieveAll
select ID, Name, DateOfBirth from Employee
gets wrapped as
namespace PersistenceLayer
{
public class Employee
{
public Guid ID;
public string Name;
public DateTime DateOfBirth;
public Employee(Guid id, string name, DateTime
dateOfBirth)
{
ID = id; Name = name; DateOfBirth = dateOfBirth;
}
// returns a collection of Employee objects...
public static ICollection RetrieveAll(SqlConnection
conn)
{
using (SqlCommand cmd = new
SqlCommand("Employee_RetrieveAll"))
{
cmd.Type = CommandType.StoredProcedure;
ArrayList list = new ArrayList();
using (SqlDataReader reader =
cmd.ExecuteReader())
{
while(reader.Read())
list.Add(new
Employee(reader.GetGuid(0), reader.GetString(1),
reader.GetDateTime(2)));
return list;
}
}
}
}
}
This kind of encapsulation affords a great deal of flexibility and makes
the business logic completely agnostic to the DB schema, which can only
be a good thing. It also provides a solid foundation apon which the
business logic can be built.
Using DataSets all over the place (i.e. through all layers of the
system) may be quicker but will result in a maintenance nightmare when
it comes to changing the DB schema at a later time. As far as I am
concerned, taking the quicker route in the short term is false economy.
Hope this helps,
Simon Wilson
Software Engineer
objectnation gmbh
Switzerland
[EMAIL PROTECTED]
Http: www.objectnation.com
Do your objects have attitude?
-----Original Message-----
From: Thomas [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 11. Juni 2002 18:10
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Data Access API
A number of people I have run into, and to some extend even I myself,
have been confused about the use of ADO.NET datasets versus the concept
of building your own Domain Object Model and using datareaders and
commands to manage the db access portion of a system.
I am wondering what experience the members of this list have had with
ADO.NET. Have you found the productivity of a dataset outweighs the
control of building your own Domain Model? What about the argument that
the functionality that comes with datasets comes at a cost and
frequently you don't need all that extra "stuff". Finally, is there any
sort of information that determines the "cost" of a datasets
functionality. By that I'm interested in an argument like " Yes
certainly the dataset has extra functionality but it only adds XXX
percent to the overhead of a given class or object." Maybe this isn't
even a consideration at all?
Anyways, the more feedback you could give the better. Or if this has
been discussed on the list, could you refer me to the posts?
Thanks
Thomas
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or subscribe to other DevelopMentor lists at
http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
