DAL design question and passing datasets

[Peter M.]

Hi all,

I'm currently designing an n-tier application and have some doubts about my
design.

I have created a Data Access layer which connects to the database (SQL
Server) and performs Select, update, delete and inserts. I use dataset
objects to pass data to and from the DAL.

In my GUI (windows forms), I use databinding to bind controls to a datatable
in the datasets which are returned from the DAL.

In order to databind controls, I must include the column names in the
datatable to which I wish to bind. These names come directly from the
database, which means my GUI has "knowledge" about database fields. I think
this is not desirable. How should this be handled? should I use strongly
typed datasets instead?

any help is appreciated!

thanks.

 

[David Browne]

Hi all,

I'm currently designing an n-tier application and have some doubts about
my design.

I have created a Data Access layer which connects to the database (SQL
Server) and performs Select, update, delete and inserts. I use dataset
objects to pass data to and from the DAL.

In my GUI (windows forms), I use databinding to bind controls to a
datatable in the datasets which are returned from the DAL.

In order to databind controls, I must include the column names in the
datatable to which I wish to bind. These names come directly from the
database, which means my GUI has "knowledge" about database fields. I
think this is not desirable. How should this be handled? should I use
strongly typed datasets instead?

Well the GUI should have "knoledge" about data. Tiers are about controling
knoledge and coupling, not eliminating them. The UI should know at
design-time, and be able to discover at runtime the name, type and basic
constraint information about every piece of data the UI is responsible for
displaying or editing.

Now whether the column names come "directly from the database" is up to you.
You return some sort of data (entities and collections, or rows and tables)
from the service interfaces to which the UI is bound. Those entities and
the public methods which operate on them is all your UI "knows". If you
change those service interface definitions, which includes changing the
entity metadata, you should expect to break your UI.

And yes, strongly typed datasets are generally perferable to non-strongly
typed ones because, among other things, they make coupling explicit and
visible to the compiler. This makes propagating changes easier and replaces
runtime errors with compile-time ones.

David

 

[Joanna Carter [TeamB]]

"Peter M." <[email protected]> a écrit dans le message de [email protected]...

| I have created a Data Access layer which connects to the database (SQL
| Server) and performs Select, update, delete and inserts. I use dataset
| objects to pass data to and from the DAL.

Having been designing DALs for a few years now, I would comment that you
really shouldn't be passing datasets anywhere; they should be fairly and
squarely hidden inside the DAL.

| In my GUI (windows forms), I use databinding to bind controls to a
datatable
| in the datasets which are returned from the DAL.

Ideally, in this n-tier scenario, the database tables should be in the DAL
and the UI should connect to the business objects which reside "in the
middle".

..NET data-aware controls can be bound to objects and lists of objects; there
really is no need to bring the tables out of the DAL just to connect to
controls; this is the old VB/Delphi way of doing things.

There is no reason why the UI should not know which properties of which
class they are displaying. The DAL should map the properties and classes to
the tables and fields used to persist the business objects.

Take a look at the articles on OPFs on my site www.carterconsulting.org.uk

Joanna

 

[Dries]

.NET data-aware controls can be bound to objects and lists of objects; there

really is no need to bring the tables out of the DAL just to connect to
controls; this is the old VB/Delphi way of doing things.

I can fully agree with that, I have been working for 2 years with
ADO.NET and I have often had troubles when trying to let my bussiness
objects inherit from ADO.NET objects. Troubles I often had, were caused
by restrictions like a DataRow can only be in one DataTable etc. Since
about 6 months I create my own business objects and I even don't use
DataSets and DataTables, even not inside my DAL.

There is no reason why the UI should not know which properties of which
class they are displaying. The DAL should map the properties and classes to
the tables and fields used to persist the business objects.

Again, I can fully agree, the idea behind an n-tier design is a top-down
architecture. The class on top knows everything about the 'interfaces'
of the classes under it. So your GUI does know which columns there are
to be found in the output of the DAL. But de DAL does not now anything
about the GUI... It is an one-way direction.

 

[David Browne]

I can fully agree with that, I have been working for 2 years with ADO.NET
and I have often had troubles when trying to let my bussiness objects
inherit from ADO.NET objects. Troubles I often had, were caused by
restrictions like a DataRow can only be in one DataTable etc. Since about
6 months I create my own business objects and I even don't use DataSets
and DataTables, even not inside my DAL.

While theres certianly nothing wrong with that approach, many of those
issues can be sucessfully addressed in .NET 2.0. Typed DataSets in .NET 2.0
are implemented as partial classes, so you can extend any DataSet, DataTable
or DataRow. In particular you can define your entities as a set of
interfaces and have your DataRow and DataTable objects implement those
interfaces. This gives you a clean-as-a-whistle business object look while
storing the actual data in DataTables which manage relationships, track
changes and handle marshaling for you.


David

 

[Peter M.]

"Peter M." <[email protected]> a écrit dans le message de
[email protected]...

Having been designing DALs for a few years now, I would comment that you
really shouldn't be passing datasets anywhere; they should be fairly and
squarely hidden inside the DAL.

Could you please elaborate on this statement? I've struggled with my design
for quite some time now.
How do you bring the data from your DAL to your business objects? Through
custom business entities? If so, where does the mapping take place? inside
the DAL? If so, doesn't that mean your DAL does a little too much work?

Ideally, in this n-tier scenario, the database tables should be in the DAL
and the UI should connect to the business objects which reside "in the
middle".

In my opinion, a (typed) dataset is just as much a busines entity object as
custom created business entity objects.

There is no reason why the UI should not know which properties of which
class they are displaying. The DAL should map the properties and classes
to
the tables and fields used to persist the business objects.

Thanks for your response.

 

[Joanna Carter [TeamB]]

"David Browne" <davidbaxterbrowne no potted (e-mail address removed)> a écrit dans
le message de news: (e-mail address removed)...

| While theres certianly nothing wrong with that approach, many of those
| issues can be sucessfully addressed in .NET 2.0. Typed DataSets in .NET
2.0
| are implemented as partial classes, so you can extend any DataSet,
DataTable
| or DataRow. In particular you can define your entities as a set of
| interfaces and have your DataRow and DataTable objects implement those
| interfaces. This gives you a clean-as-a-whistle business object look
while
| storing the actual data in DataTables which manage relationships, track
| changes and handle marshaling for you.

I'm sorry, but I must disagree with your assertion that a business object is
merely an extension of a dataset. A single object is not the same as a set
of records, which is what a dataset is.

The benefits of good OO design include the ability to model the real world
without having to model averything aroung the relational database model or
indeed any other computerified abstraction.

Business objects are nothing to do with tables, unless they are
representations of tables. A Customer class models a real world Customer;
how many people do you know who have a list of records inside them ?

Joanna

 

[Joanna Carter [TeamB]]

"Peter M." <[email protected]> a écrit dans le message de [email protected]...

| Could you please elaborate on this statement? I've struggled with my
design
| for quite some time now.
| How do you bring the data from your DAL to your business objects? Through
| custom business entities? If so, where does the mapping take place? inside
| the DAL? If so, doesn't that mean your DAL does a little too much work?

A good DAL should contain a mapping hierarchy that allows the relationships
between classes and table, properties and fields to be "registered" and
retrieved.

The DAL should have methods like :

public class ObjectStore
{
void Store<T>(T obj) {...}
void Delete<T>(T obj) {...}
List<T> RetrieveList<T>() {...}
...
}

Thus the business layer only talks to these methods; the database stuff is
hidden inside the ObjectStore class hierarchy.

It is the job of the classes that make up the DAL to translate objects to
records in tables and back again. This is no simple task and can mean
designing several classes in the DAL to supply the necessary functionality.

See the articles on my site www.carterconsulting.org.uk or you might like to
look at Scott Ambler's articles on Object Persistence (Google is your
friend)

| In my opinion, a (typed) dataset is just as much a busines entity object
as
| custom created business entity objects.

As I have said in another post, any class that represents a list of records
cannot be equated to a business class that does not model a list of objects.
One is a list of records, the other is a single object.

Joanna

 

[David Browne]

"David Browne" <davidbaxterbrowne no potted (e-mail address removed)> a écrit dans
le message de news: (e-mail address removed)...

| While theres certianly nothing wrong with that approach, many of those
| issues can be sucessfully addressed in .NET 2.0. Typed DataSets in .NET
2.0
| are implemented as partial classes, so you can extend any DataSet,
DataTable
| or DataRow. In particular you can define your entities as a set of
| interfaces and have your DataRow and DataTable objects implement those
| interfaces. This gives you a clean-as-a-whistle business object look
while
| storing the actual data in DataTables which manage relationships, track
| changes and handle marshaling for you.

I'm sorry, but I must disagree with your assertion that a business object
is
merely an extension of a dataset.

Never said it was. Just that the partial class DataSet implementation
allows you to overlay a buniess object design over the DataSet storage.

A single object is not the same as a set of records, which is what a
dataset is.

No a DataSet is a set of sets. A DataRow stores the data for a single
entity, a DataTable stores the data for a collection of entities, and a
DataSet stores the data for one or more related collections of entities.

The benefits of good OO design include the ability to model the real world
without having to model averything aroung the relational database model or
indeed any other computerified abstraction.

Um, what is OO if not a "computerified abstraction"? OO is a modeling
technology. Relation Databases are a modeling technology. We're just
talking about how to make them work together.

Business objects are nothing to do with tables, unless they are
representations of tables. A Customer class models a real world Customer;
how many people do you know who have a list of records inside them ?

Agreed. In the model I propose a customer would be modeled by an interface,
ICustomer. An ICustomer implementation might store its data in a DataRow,
or in some fields, or in an XML document or some sort of BLOB. But it has
all the right data and methods for a customer object, and client code need
not know anything about the actual data storage.

David

 

[Frans Bouma [C# MVP]]

No a DataSet is a set of sets. A DataRow stores the data for a
single entity, a DataTable stores the data for a collection of
entities, and a DataSet stores the data for one or more related
collections of entities.

No. A Datarow is a container for the data of an entity, but it can't
live on its own, for the simpel reason that the definitions for each
cell isn't stored in the datarow.

This is best illustrated by comparing a datatable and an entity
collection which can store entities of type 'person'. I can also store
derived entities, like 'employee' in that entitycollection, but I can't
in the datatable. That is: unless I add columns to the datatable, but
then each datarow has those columns as well.

Um, what is OO if not a "computerified abstraction"? OO is a
modeling technology. Relation Databases are a modeling technology.
We're just talking about how to make them work together.

a relational database a modelling technology? I thought a relational
MODEL was the result of applying modelling technology on analysis
results and a relational database the implementation of the relational
model in a RDBMS.

Agreed. In the model I propose a customer would be modeled by an
interface, ICustomer. An ICustomer implementation might store its
data in a DataRow, or in some fields, or in an XML document or some
sort of BLOB. But it has all the right data and methods for a
customer object, and client code need not know anything about the
actual data storage.

a datarow isn't a good choice, as it cant live alone. If you pass a
'customer' which is based on a datarow to another method, you HAVE TO
pass the datatable the datarow belongs to as well.

FB

--

 

[Joanna Carter [TeamB]]

"David Browne" <davidbaxterbrowne no potted (e-mail address removed)> a écrit dans
le message de news: (e-mail address removed)...

| Never said it was. Just that the partial class DataSet implementation
| allows you to overlay a buniess object design over the DataSet storage.

And that is one of the problems. A class should be a description of data and
related behaviour. It should have clearly defined boundaries and, even more
so, responsibilities.

Responsibility Driven Design is a very powerful technique that ensures that
every class does exactly what it should do, no more, no less. It is not the
responsibility of a Customer or an Invoice to know about dataset behaviour,
but purely the attributes and behaviour of being a Customer.

| No a DataSet is a set of sets. A DataRow stores the data for a single
| entity, a DataTable stores the data for a collection of entities, and a
| DataSet stores the data for one or more related collections of entities.

Sorry, Delphi datasets are single table entities, I still haven't made the
mental switch )

| Um, what is OO if not a "computerified abstraction"? OO is a modeling
| technology. Relation Databases are a modeling technology. We're just
| talking about how to make them work together.

Ah yes, but relational theory, foreign keys, referential integrity, etc are
all much more "computerified" than stating properties like Name, Address,
Amount, etc as being attributes of an entity and Move(), Collide(), etc
being models of real world behaviour.

| Agreed. In the model I propose a customer would be modeled by an
interface,
| ICustomer. An ICustomer implementation might store its data in a DataRow,
| or in some fields, or in an XML document or some sort of BLOB. But it has
| all the right data and methods for a customer object, and client code need
| not know anything about the actual data storage.

FMPOV, separating implementation from interface does not necessarily mean
that implementation should have knowledge beyond the responsibilities
expected of the interface.

In the perfect world, we would not need databases, we should be able to have
a version of Windows (or other) operating system that allows us to just
create objects and keep them alive without having to store them to disk just
in case the power gets switched off.

In such a world, the idea of storage would only extend to keeping objects in
lists; there would be no need to translate from properties of classes to
fields of tables.

The only reason we need datasets, tables, fields, foreign keys, referential
integrity constrints, stored procedures, views, etc is because we had to
devise a mechanism for preventing data loss when the power get switched off.

My argument, and that of many other OO gurus, is that storage/retrieval
functionality is something optional and only needs implementing in this
imperfect world of interruptible power supply. Given that it *does* need
implementing, let's keep that functionality separate from the business
object world, thus allowing us to change, improve or update the technology
that is used to implement the storage of those objects.

Partial classes certainly have their place, although I remain to be
convinced of their likely pervasiveness. Certainly, they seem like a good
idea for form design, where they allow the IDE to maintain the visual side
of the form's design whilst allowing the developer to work in an uncluttered
part of the form class for other logic.

However, I do not believe that dividing a class up into several partial
classes means that we can introduce behaviour not intended to be part of the
original specification of the total class. This leads to inexperienced and
unwise developers adding more and more "partial" classes so that, in the
end, they have one class for the whole application !

In the last ten years of Delphi, I have consulted for companies where
developers have managed to get a whole application's logic in the main form
code unit which may possess many tens of thousands of lines of code !!! .NET
namespaces equate to Delphi units in some ways, I just hope I don't see too
many multiple module "partial" classes :-(

Joanna

 

[jimmy john bill roy earl carl smith]

Business objects are nothing to do with tables, unless >they are

representations of tables. A Customer class models a real >world Customer;
how many people do you know who have a list of records >inside them ?

I don't know anyone with a list of records in them, I also don't know of
any one with a list of properties in them. This debate is ludicrous
"This way is more perfect than that way."

If you really want the end all be all quit playing around with 4GL .net
and go write some C++, then you can do whatever you want.

If I am ever in the position of having an ulimited amount of time and
money from my customer I am not going to write anything in .net (or any
other existing language for that matter) I am going to create my own!!!
While I am at it I will create my own networking protocol to address all
the security issues with the current crop!

DataSet or Biz Object - either way you are going to have to do some
actual coding and thinking - I know, I know that is crazy talk!!