strongly typed datasets in c#

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi newsgroup,

I'm new to ADO.NET. I want to use strongly typed datasets, to reflect my
business objects from the database. I have e.g. an object "user" with the
properties name, telno, login, password, etc. I'm able to access all these
properties in the code. But now I want to add business logic to the objects.
E.g. a function "generateRSAKeyPair". What is the usual way to implement
business logic? Should I derive the dataset class and add the functionality
in there? Or should I write something like a wrapper class around the dataset
where the business logic is implemented?

And how do I handle relations between objects depending on the way for
implementing the business logic. I would need to write my own collection
classes which cater for data integrity upon chances.

Thanks in advance
Patrick
 
Hi,

it depends on the requirement for which you should extend a dataset. If your
business logic is strongly tied with the data tier, you can consider writing
it by extending the dataset. On the other hand, if your DAL is is in a
separate tier itself or you want some enhanced security, you can built a
custom wrapper around your dataset class.

HTH,
Joyjit
 
You are asking some pretty big questions. There are many theories on objects.
If you go to the webcast page and look at last August, you will find a
webcast from Paul Sherriff that talks about making business objects from
datasets. It is an easy pattern to repeat and maintain in your application.
An OO purist might argue against it, however.

From "pure OO" standard, you either create properties based on the items in
a single table, or you abstract across multiple tables. The latter is
commonly acronymed as ORM (Object-Relational Mapping). You will see this in
the Orcas version of Visual Studio (Longhorn timeframe) in a technology
called ObjectSpaces (dropped from Visual Studio 2005).

For simplicity, using Sherriff's model is not a bad idea. The webcast is
quite good, although I would have a harder line between the tiers. You can
adopt an ORM approach, but you are largely on your own unless you create the
abstraction through stored procedures, as there are no easy tools for ORM in
the current implementation.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Back
Top