Data binding vs n-tier

[Kathleen Dollard]

Jeff,

> I noticed that Microsoft went through a lot of trouble adding data binding
> to windows forms, even to the point where we can drag and drop connections
> and data sets right on to a form. The data grid control _only_ supports
data
> binding. What I don't understand is why? In 3-tier or n-tier architecture,
> only presentation related code goes into the ui. Business rules should
never
> be in the ui, let alone data access code. Doesn't this go against
everything
> they've been telling us about architecture design? What am I missing?

It is just that isolated samples rarely give you a sufficiently robust
picture.

DataBindings can be to anything. You need a mechanism to cross the
boundaries in your three tiered application. I find a derived dataset to be
the best tool for this, but it certainly isn't the only one.

You neatly box your data access into classes in one tier. This produces
data, perhaps a derived dataset and updates data. Your middle tier contains
business logic, and can easily contain data rules that might otherwise drift
toward the UI. This is because validation can (and in my opinion should)
take place in data table events, rather than UI events (at least for
WinForms). You can then bind to the data and still retain control over its
access.

That is rather superficial. Is it enough to get you started?

Hints:
If you like drag drop, etc. Add a "Component" to your data layer and drag
drop there. Just be aware that everything you drop gets instantiated with
the component.

Strongly typed datasets are great, imo. They give you design time support.
That is what I further derive

The "DataSet" option in the Data toolbox for your form allows you a quick
way to add a strongly typed data set to your form. This then allows design
time binding

Design time databinding of a base form and visual inheritance do not mix.
You will have to set yoru base form databindings in code.

There are some quirks to databinding. It does work, and I'd suggest asking
for help quickly when it seems to not be working.

Kathleen

"Jeff Pipes" <JeffP622@msn.com> wrote in message
news:3cc8281c$1@10.1.10.29...
>
> I noticed that Microsoft went through a lot of trouble adding data binding
> to windows forms, even to the point where we can drag and drop connections
> and data sets right on to a form. The data grid control _only_ supports
data
> binding. What I don't understand is why? In 3-tier or n-tier architecture,
> only presentation related code goes into the ui. Business rules should
never
> be in the ui, let alone data access code. Doesn't this go against
everything
> they've been telling us about architecture design? What am I missing?
>
> -Jeff

[Jeff Pipes]

I noticed that Microsoft went through a lot of trouble adding data binding
to windows forms, even to the point where we can drag and drop connections
and data sets right on to a form. The data grid control _only_ supports data
binding. What I don't understand is why? In 3-tier or n-tier architecture,
only presentation related code goes into the ui. Business rules should never
be in the ui, let alone data access code. Doesn't this go against everything
they've been telling us about architecture design? What am I missing?

-Jeff

[Scott Hutchinson]

A key thing to keep in mind is that you can bind the UI controls to a
disconnected DataSet, which is an in-memory cache of the data. Also the
DataSet class is completely data source agnostic--it doesn't know and
doesn't care where the data came from (or in other words, it's independent
of the data layer). In an n-tier design, the parts that DO know about the
data source (i.e., the Connection, Command, and/or DataAdapter objects)
should be kept out of the UI/presentation tier. So, this type of data
binding shouldn't prevent you from implementing a good n-tier architecture.

If, on the other hand, you bind the UI controls directly to the data source
using a connected DataReader, which is usually NOT data source agnostic,
then your concerns are more relevant.

Scott Hutchinson
s.c.o.t.t.h.u.t.c.h.i.n.s.o.n@usa.net

"Jeff Pipes" <JeffP622@msn.com> wrote in message
news:3cc8281c$1@10.1.10.29...
>
> I noticed that Microsoft went through a lot of trouble adding data binding
> to windows forms, even to the point where we can drag and drop connections
> and data sets right on to a form. The data grid control _only_ supports
data
> binding. What I don't understand is why? In 3-tier or n-tier architecture,
> only presentation related code goes into the ui. Business rules should
never
> be in the ui, let alone data access code. Doesn't this go against
everything
> they've been telling us about architecture design? What am I missing?
>
> -Jeff

[Patrick Ireland]

Jeff,

Kathleen gave you good information.
I have not had the pleasure yet of
implementing a system using her
approach, I hope that an opportunity
presents itself that I might.

I attack the UI/BR interface a little
different. I divide the editting of
a data field into 2 modes. I use the
terms suitability and compatibility.

The field must first meet suitability,
i.e., numbers in numeric fields. This
class of editing can be can be testing
not knowing anything about data on a
database.

After the fields meet the suitability
requirement, then I apply the business
rules. Here the fields, singlely and
in combination must meet compatibility
with the database.

I realize that I can loose the data
binding of the UI to the database but
it allows me to isolate the business
rules including placing them on a
completely separate machine, a separate
language like yeek COBOL, etc.

So as you can see, there is more than
1 way to skin a cat. Which is more
correct? Neither, try to use the
approach that best fits the circumstances.

Have you missed anything? No, it is
just a matter of implementation needs.

[Bill Storage]

"Kathleen Dollard" <kathleen@mvps.org> wrote in message
news:3cc831d8$1@10.1.10.29...
>
> You neatly box your data access into classes in one tier. This produces
> data, perhaps a derived dataset and updates data. Your middle tier
contains
> business logic, and can easily contain data rules that might otherwise
drift
> toward the UI. This is because validation can (and in my opinion should)
> take place in data table events, rather than UI events (at least for
> WinForms). You can then bind to the data and still retain control over its
> access.
>

Kathleen-
Are you happy with .Net's support for 3-tier dev with binding as you
describe? I think I'd rather see a cleaner means of putting a bunch of
DataAdapters on a component in one tier (in one project) and then being able
to bind to DataSets exposed by that tier in the client project ( a bit like
the maligned VB6 DateEnvironment). I'd like a wizard to at least add methods
to the data-provider component based on the datasets and DataAdpater
instances it houses. Then I'd like the client project's Properties Browser
to be able to see the provider's datasets for setting up databinding. I've
played around with automating this myself, but it looks like a fairly large
task.

Bill

[Kathleen Dollard]

Bill,

> Are you happy with .Net's support for 3-tier dev with binding as you
> describe? I think I'd rather see a cleaner means of putting a bunch of
> DataAdapters on a component in one tier (in one project) and then being
able
> to bind to DataSets exposed by that tier in the client project ( a bit
like
> the maligned VB6 DateEnvironment). I'd like a wizard to at least add
methods
> to the data-provider component based on the datasets and DataAdpater
> instances it houses. Then I'd like the client project's Properties Browser
> to be able to see the provider's datasets for setting up databinding. I've
> played around with automating this myself, but it looks like a fairly
large
> task.

I am happy that they didn't try to do too much with three tier development
too quick. They are bound to screw somethings up (command builder for
example, and IMO, the strongly typed dataset has major flaws) and having to
roll our own lets us pick and choose. That said, do I hope it will expand
significantly in the future, and do I hope we won't all have to write
auto-gen tools, yes and yes. As they do this,I hope it will be far more
under our control than the strongly typed dataset generation is.

I am doing things a little differently than what you describe would fit, and
I guess our collective conciousness finding the smartest way, then
automating it sounds more reliable than MS dictating a mechanism. That
dictation, I think, is why things like <=VB6 databinding and the data
environment failed.

(FWIW, I have a DLL that is separate from my data access layer that exposes
strongly typed datasets that have been further derived to add a couple
things inlcuding a Fill and Update method. The Fill method says "send
thyeslf to your datalayer" and the UI has no clue of this. It means that the
specific data layer component is well hidden, and in fact the data might not
use a data access layer at all (retrieval from local XML cache for off line
work, for example). When the dataset arrives at the data layer, it figures o
ut how to fill it.

Based on this what I'd like, and am in the process of writing, is a wizard
that takes a stored proc, actually runs it (because my DBA writes hard to
parse stored procs) and creates datacommands in the data layer, strongly
typed datasets in the middle tier, and the associated changes to the
strongly typed dataset and derived extensions, including parameter support.
It is quite doable, I am just still solidifying exactly what I want before I
autogen too much code. For example, I am currently losing enthusiasm for
creating DataAdapters at design time and expect to completely abandon them
in favor of creating the adapater at run time based on the commands created
at design time. I am also coming to detest the .NET component surface for
this puprose more every day and wish that were a simple listview interface
and that it created, but did not instantiate the items on the surface when
the "component like thing" was instantiated. Now _that_ is somethng that
sounds like a large task to me.

Currently, I am happy enough with what my UI sees, as the entire middle tier
DLL(s) interface is of interest to it.)

Looking forward to your further thoughts!
Kathleen

"Bill Storage" <storage@bplusmylastname.com> wrote in message
news:3cc8a3d1@10.1.10.29...
>
> "Kathleen Dollard" <kathleen@mvps.org> wrote in message
> news:3cc831d8$1@10.1.10.29...
> >
> > You neatly box your data access into classes in one tier. This produces
> > data, perhaps a derived dataset and updates data. Your middle tier
> contains
> > business logic, and can easily contain data rules that might otherwise
> drift
> > toward the UI. This is because validation can (and in my opinion should)
> > take place in data table events, rather than UI events (at least for
> > WinForms). You can then bind to the data and still retain control over
its
> > access.
> >
>
> Kathleen-
> Are you happy with .Net's support for 3-tier dev with binding as you
> describe? I think I'd rather see a cleaner means of putting a bunch of
> DataAdapters on a component in one tier (in one project) and then being
able
> to bind to DataSets exposed by that tier in the client project ( a bit
like
> the maligned VB6 DateEnvironment). I'd like a wizard to at least add
methods
> to the data-provider component based on the datasets and DataAdpater
> instances it houses. Then I'd like the client project's Properties Browser
> to be able to see the provider's datasets for setting up databinding. I've
> played around with automating this myself, but it looks like a fairly
large
> task.
>
> Bill
>
>
>
>

[Bill Storage]

"Kathleen Dollard" <kathleen@mvps.org> wrote in message
news:3cc98020$1@10.1.10.29...
> Bill,
>
>

Sounds like your experience and sentiments have been similar to mine. What
you describe here is very similar to what many of us (sounds like you too)
were doing with VB6/ADO - codegen of command objects, etc. I'll put together
some more coherent thoughts and get back to you.

Bill

[Jeff Pipes]

Ok, let me re-phrase my original question. Yes, you can databind to regular
classes and still keep your data access in a separate tier. But what about
dragging and dropping actual connections on to your form and accessing your
data from there? Isn't that a violation of 3-tier architecture?

-Jeff


"Kathleen Dollard" <kathleen@mvps.org> wrote:
>Jeff,
>
>> I noticed that Microsoft went through a lot of trouble adding data binding
>> to windows forms, even to the point where we can drag and drop connections
>> and data sets right on to a form. The data grid control _only_ supports
>data
>> binding. What I don't understand is why? In 3-tier or n-tier architecture,
>> only presentation related code goes into the ui. Business rules should
>never
>> be in the ui, let alone data access code. Doesn't this go against
>everything
>> they've been telling us about architecture design? What am I missing?
>
>It is just that isolated samples rarely give you a sufficiently robust
>picture.
>
>DataBindings can be to anything. You need a mechanism to cross the
>boundaries in your three tiered application. I find a derived dataset to
be
>the best tool for this, but it certainly isn't the only one.
>
>You neatly box your data access into classes in one tier. This produces
>data, perhaps a derived dataset and updates data. Your middle tier contains
>business logic, and can easily contain data rules that might otherwise drift
>toward the UI. This is because validation can (and in my opinion should)
>take place in data table events, rather than UI events (at least for
>WinForms). You can then bind to the data and still retain control over its
>access.
>
>That is rather superficial. Is it enough to get you started?
>
>Hints:
>If you like drag drop, etc. Add a "Component" to your data layer and drag
>drop there. Just be aware that everything you drop gets instantiated with
>the component.
>
>Strongly typed datasets are great, imo. They give you design time support.
>That is what I further derive
>
>The "DataSet" option in the Data toolbox for your form allows you a quick
>way to add a strongly typed data set to your form. This then allows design
>time binding
>
>Design time databinding of a base form and visual inheritance do not mix.
>You will have to set yoru base form databindings in code.
>
>There are some quirks to databinding. It does work, and I'd suggest asking
>for help quickly when it seems to not be working.
>
>Kathleen

[Jeff Pipes]

"Kathleen Dollard" <kathleen@mvps.org> wrote:
>the strongly typed dataset has major flaws

How so? Sorry to ask so many questions but I'm still new to this.

-Jeff

[Jeff Pipes]

Whenever I see someone give a demostration of ado.net, they're always dragging
and dropping connections, tables, etc right on to the design surface of the
form. And I think to myself what happened to 3-tier?

-Jeff

"Scott Hutchinson" <scotthutchinson@usa.net> wrote:
>A key thing to keep in mind is that you can bind the UI controls to a
>disconnected DataSet, which is an in-memory cache of the data. Also the
>DataSet class is completely data source agnostic--it doesn't know and
>doesn't care where the data came from (or in other words, it's independent
>of the data layer). In an n-tier design, the parts that DO know about the
>data source (i.e., the Connection, Command, and/or DataAdapter objects)
>should be kept out of the UI/presentation tier. So, this type of data
>binding shouldn't prevent you from implementing a good n-tier architecture.
>
>If, on the other hand, you bind the UI controls directly to the data source
>using a connected DataReader, which is usually NOT data source agnostic,
>then your concerns are more relevant.
>
>Scott Hutchinson
>s.c.o.t.t.h.u.t.c.h.i.n.s.o.n@usa.net
>
>"Jeff Pipes" <JeffP622@msn.com> wrote in message
>news:3cc8281c$1@10.1.10.29...
>>
>> I noticed that Microsoft went through a lot of trouble adding data binding
>> to windows forms, even to the point where we can drag and drop connections
>> and data sets right on to a form. The data grid control _only_ supports
>data
>> binding. What I don't understand is why? In 3-tier or n-tier architecture,
>> only presentation related code goes into the ui. Business rules should
>never
>> be in the ui, let alone data access code. Doesn't this go against
>everything
>> they've been telling us about architecture design? What am I missing?
>>
>> -Jeff
>
>

[Kathleen Dollard]

Jeff,

> Ok, let me re-phrase my original question. Yes, you can databind to
regular
> classes and still keep your data access in a separate tier. But what about
> dragging and dropping actual connections on to your form and accessing
your
> data from there? Isn't that a violation of 3-tier architecture?

Yes, avoid putting connections or adapters on your form. It limits reuse,
devestates 3-tier design and is entirely unnecessary.

Kathleen

[Kathleen Dollard]

Jeff,

> >the strongly typed dataset has major flaws
>
> How so? Sorry to ask so many questions but I'm still new to this.

You have to take that in the context it was stated. Bill asked whether I was
happy with .NET's support for 3-tier architecture. In the context of whether
I am happy, yes it has flaws.

The major problem is you have to change the strongly typed dataset (which
means your changes are overwritten so you have to do this a lot) to
instantiate derived strongly typed DataTables. The primary reason you might
want to do this is to handle the ColumnUpdating, etc events right in the
DataTable, but there are some other reasons. Also, the handling of nulls is
not flexible enough, imo (you don't have an option to use the SQLtypes). You
also don't have much flexibility in whether particular methods, such as that
AddNew with all of the field data, are included. Strongly typed datasets
really need to support Enums for properties, although I haven't quite
figured out a good way to define that.

I hope we will move toward more of a template driven system where different
architectures can be easily created via autogenned code.

Kathleen

[Alex Rosen]

> The major problem is you have to change the strongly typed dataset (which
> means your changes are overwritten so you have to do this a lot) to
> instantiate derived strongly typed DataTables. The primary reason you
might
> want to do this is to handle the ColumnUpdating, etc events right in the
> DataTable, but there are some other reasons. Also, the handling of nulls
is
> not flexible enough, imo (you don't have an option to use the SQLtypes).
You
> also don't have much flexibility in whether particular methods, such as
that
> AddNew with all of the field data, are included. Strongly typed datasets
> really need to support Enums for properties, although I haven't quite
> figured out a good way to define that.

I think a major problem with strongly-typed DataSets is the number of
different ways they can be produced and the different results you get from
each technique. This overly complicates the learning curve imo. I took some
notes as I went up that curve and include them below to hopefully help
others avoid some pain. Before the notes though I will also add that it
would be nice if there was a way to automatically generate them with the
table relationships (maybe there is -- I guess I didn't try hard on this). I
manually add the relationships using the XML designer after the xsd is
generated. I also add my own annotations which is a nice feature but is not
automated at all. I keep the lines I add in a file for manual copy/paste
after every re-gen at the moment but will automate this some day.

Finally, I'm not sure I agree with where you are going with adding more
logic into the strongly-typed DataSets. I see them as a Data Transfer
Objects (http://www.martinfowler.com/isa/dataTransferObject.html). They
already have a lot of general purpose data manipulation logic (sorting,
filtering, adding, removing) and validation logic (type, length,
nullability). I guess I'm not clear on whether you are advocating extending
the strongly-typed DataSet to turn it into a middle tier component or if you
are mainly using it for passing data. If you are turning them into the
business logic components that sounds like a reasonable approach. If you are
talking about using them for passing data but also adding more logic then I
feel like there is a problem because the business logic is getting spread
out and would be more difficult to maintain. My approach is to only add
general purpose functionality or things that deal with straightforward
representation and enforcement of the data structure to the DataSets I
create. Any more complex rules go in business logic components that process
DataSets. I kind of wish MS would give some guidance on these principles so
we would have some type of standard. There are too many ways of doing things
and I would like to just work with a set of patterns that work reasonably
well and are well worn by the community.

OK... Here are those notes...

Strongly-typed DataSets can be generated in at least four ways:

1. Populate a DataSet with a sample of the data you wish to represent in the
Dataset and then use the DataSet's WriteXMLSchema method to generate the xsd
file. Finally, use the xsd tool to generate a class based on the schema. The
problem with this method is that important information about keys,
nullability, and maximum lengths of fields is not included in the xsd file
and therefore is also missing from the class.

2. Add a new DataSet item to the project and then drag a table onto the
design surface. This method generates an xsd that includes more information
than the previous approach but still lacks the maximum length information.

3. Add a DataAdapter to a form and then choose the Generate DataSets link
from the bottom of the properties window. This yields the same results as
#2.

4. Use the FillSchema method of the DataAdapter to generate the xsd. This
method includes the most information about the DataSet. Here is a code
excerpt that works with a previously opened connection:

' Set up a data adapter object.
Dim strSelect As String = "SELECT * FROM VMUser"
Dim da As New SqlDataAdapter(strSelect, cn)
' Load a data set.
Dim ds As New DataSet("VMUserDataSet")
da.FillSchema(ds, SchemaType.Source)

The WriteXMLSchema method of the DataSet is then used to generate the xsd
file.

The strongly-type DataSets are more standard, provide a nicer coding style
and better Intellisense support. However, they are harder to comprehend and
definitely more of a hassle to maintain as any change in the database schema
requires regeneration of the class. Nevertheless, after researching it and
learning about technique number 4 I now think the application should use
strongly-typed DataSets. The biggest headache is regenerating them when
changes are made to the database schema. Before switching the app to the new
way, code needs to be developed to regenerate each DataSet type in use to
reduce maintenance time. The code should dynamically determine the project's
location and regenerate the xsd file over the existing one in the project.
To (re)generate the DataSet class file you need to set the Custom Tool
property of the XSD file to MSDataSetGenerator. Simply setting the property
seems to cause the tool to be run. It may be run again by right clicking on
the XSD file and selecting "Run Custom Tool".

[Kathleen Dollard]

Alex,

I have recently been workign with code driven methods to build the XSD so
appreciate your comments. My main reason was to snag the relations. I am
still working on getting my macros to modify the dumb strongly typed dataset
completed. On this project I want to be able to inherit from the strongly
typed tables so that validation events are handled in the table, not the
dataset. While it is not in the XSD, I believe that the size is in the
resulting datacolumns if you fill the dataset using AddWithPrimaryKey.

> Finally, I'm not sure I agree with where you are going with adding more
> logic into the strongly-typed DataSets. I see them as a Data Transfer
> Objects (http://www.martinfowler.com/isa/dataTransferObject.html). They
> already have a lot of general purpose data manipulation logic (sorting,
> filtering, adding, removing) and validation logic (type, length,
> nullability). I guess I'm not clear on whether you are advocating
extending
> the strongly-typed DataSet to turn it into a middle tier component or if
you
> are mainly using it for passing data. If you are turning them into the
> business logic components that sounds like a reasonable approach. If you
are
> talking about using them for passing data but also adding more logic then
I
> feel like there is a problem because the business logic is getting spread
> out and would be more difficult to maintain.

I didn't follow your distinction between turning them in to business logic
components and not. We don't have much business logic outside the database
except for validation rules that apply to single fields. Therefore, I think
it entirely appropriate to keep it as close to the data as possible. Where
there is a lot of true business logic, I think you need a separate set of
classes, and that those classes may not parallel the data tables closely. So
perhaps we agree, I am not sure.

Kathleen

[Alex Rosen]

> On this project I want to be able to inherit from the strongly
> typed tables so that validation events are handled in the table, not the
> dataset.

Got ya.

> While it is not in the XSD, I believe that the size is in the
> resulting datacolumns if you fill the dataset using AddWithPrimaryKey.

I'll have to check out that option. I did correspond with MS on this issue
and someone there told me they left out that information I mentioned because
it made the XSD ugly in the designer. Sounded odd to me. They suggested the
4th method which is what I have adopted but if adding this option works
maybe I'll switch back.

> I didn't follow your distinction between turning them in to business logic
> components and not. We don't have much business logic outside the database
> except for validation rules that apply to single fields. Therefore, I
think
> it entirely appropriate to keep it as close to the data as possible. Where
> there is a lot of true business logic, I think you need a separate set of
> classes, and that those classes may not parallel the data tables closely.
So
> perhaps we agree, I am not sure.

I see what you are saying and that architecture makes sense to me for the
kind of app you described. I am building an app without much true business
logic as well but I am putting what logic there is into the separate
classes. Maybe it is over-engineering but I am trying to follow what I think
MS was proposing in their enterprise application samples. Sad thing is I
found problems with those samples after I started down the path so now I
have somewhat of a mish mash that I am slowly making more uniform as I
learn. Good thing this app is internal and I'll be able to play with it
later. I don't see much guidance anywhere about how to handle the biz logic.
I agree for simple validation stuff you can just put it in overrides of the
code generated by the strongly-typed DataSet tool. When we get into more
complex stuff I have tried to follow the Facade Layer/Business Rules layer
approach MS uses in their samples. I have run into some mental roadblocks
though. I am going to try to put together what the issues I have hit are in
a separate thread (maybe in a few days) so I can get feedback from the
group. Like others, I have been reading and practicing but I haven't hit an
approach that seems ideal.