Technique??? Use a web user control to store & share data access component groups

Hello all...

I'm coming from a Borland Delphi background. Delphi has a specific
component called a Data Module. In the designer the Data Module behaves
like a windows form. A developer can drop non-visual (controls) on the data
module surface and wire them up and create procedures, functions, event
procedures. In the source file (code behind file) the Data Module is a
class, and the dropped components are public properties. The event
procedures/functions are public as well. The developer can add additional
public/private/protected procedures, functions, and data members. This
module can be shared among several other modules within the project, by
using a syntax similar to using clause in C#.

The benefits this provides is what I'm attempting to mimic in VS.NET 2003.
If one is designing a single feature of an application, the feature could
most likely be composed of several modules (source files and forms). All of
the data access code and controls for the feature can be centralized by
placing it in a data module. All of the non-data access centric code for
the feature, located in other modules, would talk the to the data module(s)
created for the feature. Data modules even support sub-classing via visual
inheritance.

So I came up with a nice idea of dropping data access controls on to a web
user control to centralize the data access code and controls. However, I
wanted to know what other more experienced VS.NET developers think about the
idea. Are there any pitfalls that could result from this approach? I would
hate to paint myself into a corner. Could I sub-class, via visual form
inheritence, a web user control and further enhanced as well?

Looking forward to your feedback. Cheers.
--JQPDev

re: Technique??? Use a web user control to store & share data access component groups

> So I came up with a nice idea of dropping data access controls on to a web[color=blue]
> user control to centralize the data access code and controls. However, I[/color]

Surprise. You didn't come up with the idea in the first place. It already
exists in Visual Studio.Net. You might be interested ot know that Anders
Hejlsberg, one of the principal architects of Turbo Pascal and Delphi, was
one of the principal architects of the C# language.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.


"jqpdev" <jqpdev@counterattack.com> wrote in message
news:#1ciWlB9DHA.3404@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hello all...
>
> I'm coming from a Borland Delphi background. Delphi has a specific
> component called a Data Module. In the designer the Data Module behaves
> like a windows form. A developer can drop non-visual (controls) on the[/color]
data[color=blue]
> module surface and wire them up and create procedures, functions, event
> procedures. In the source file (code behind file) the Data Module is a
> class, and the dropped components are public properties. The event
> procedures/functions are public as well. The developer can add additional
> public/private/protected procedures, functions, and data members. This
> module can be shared among several other modules within the project, by
> using a syntax similar to using clause in C#.
>
> The benefits this provides is what I'm attempting to mimic in VS.NET 2003.
> If one is designing a single feature of an application, the feature could
> most likely be composed of several modules (source files and forms). All[/color]
of[color=blue]
> the data access code and controls for the feature can be centralized by
> placing it in a data module. All of the non-data access centric code for
> the feature, located in other modules, would talk the to the data[/color]
module(s)[color=blue]
> created for the feature. Data modules even support sub-classing via[/color]
visual[color=blue]
> inheritance.
>
> So I came up with a nice idea of dropping data access controls on to a web
> user control to centralize the data access code and controls. However, I
> wanted to know what other more experienced VS.NET developers think about[/color]
the[color=blue]
> idea. Are there any pitfalls that could result from this approach? I[/color]
would[color=blue]
> hate to paint myself into a corner. Could I sub-class, via visual form
> inheritence, a web user control and further enhanced as well?
>
> Looking forward to your feedback. Cheers.
> --JQPDev
>
>[/color]

re: Technique??? Use a web user control to store & share data access component groups

Thanks Kevin for the update. I knew about Anders. Actually he was
proprositioned by Microsoft a while back. You can call it a very sneaky or
a very smart move on the part of M$. Without Anders we wouldn't have
VB.NET, or C#.net. VB.NET has the equivalent feature set of Delphi v4 and
v5. The same could be said for C#.net in VS.NET 2003. Whidbey/dotnet 2.0
will add some nice features. However, Borland has dotnet enabled all of
their products. I jumped ship because I couldn't find readily available
work in NYC with Delphi. There were some, but mostly scarce.

....and now back to my question. I'm saying that I was the only person to
land on the idea of centralizing data access code & controls in web user
controls. Can you give me some additional details on the pros and cons of
this approach? I'm using VS.NET 2003 if that makes any difference.


"Kevin Spencer" <kevin@takempis.com> wrote in message
news:O0ojkTK9DHA.2404@TK2MSFTNGP12.phx.gbl...[color=blue][color=green]
> > So I came up with a nice idea of dropping data access controls on to a[/color][/color]
web[color=blue][color=green]
> > user control to centralize the data access code and controls. However,[/color][/color]
I[color=blue]
>
> Surprise. You didn't come up with the idea in the first place. It already
> exists in Visual Studio.Net. You might be interested ot know that Anders
> Hejlsberg, one of the principal architects of Turbo Pascal and Delphi, was
> one of the principal architects of the C# language.
>
> --
> HTH,
> Kevin Spencer
> .Net Developer
> Microsoft MVP
> Big things are made up
> of lots of little things.
>
>
> "jqpdev" <jqpdev@counterattack.com> wrote in message
> news:#1ciWlB9DHA.3404@TK2MSFTNGP09.phx.gbl...[color=green]
> > Hello all...
> >
> > I'm coming from a Borland Delphi background. Delphi has a specific
> > component called a Data Module. In the designer the Data Module behaves
> > like a windows form. A developer can drop non-visual (controls) on the[/color]
> data[color=green]
> > module surface and wire them up and create procedures, functions, event
> > procedures. In the source file (code behind file) the Data Module is a
> > class, and the dropped components are public properties. The event
> > procedures/functions are public as well. The developer can add[/color][/color]
additional[color=blue][color=green]
> > public/private/protected procedures, functions, and data members. This
> > module can be shared among several other modules within the project, by
> > using a syntax similar to using clause in C#.
> >
> > The benefits this provides is what I'm attempting to mimic in VS.NET[/color][/color]
2003.[color=blue][color=green]
> > If one is designing a single feature of an application, the feature[/color][/color]
could[color=blue][color=green]
> > most likely be composed of several modules (source files and forms).[/color][/color]
All[color=blue]
> of[color=green]
> > the data access code and controls for the feature can be centralized by
> > placing it in a data module. All of the non-data access centric code[/color][/color]
for[color=blue][color=green]
> > the feature, located in other modules, would talk the to the data[/color]
> module(s)[color=green]
> > created for the feature. Data modules even support sub-classing via[/color]
> visual[color=green]
> > inheritance.
> >
> > So I came up with a nice idea of dropping data access controls on to a[/color][/color]
web[color=blue][color=green]
> > user control to centralize the data access code and controls. However,[/color][/color]
I[color=blue][color=green]
> > wanted to know what other more experienced VS.NET developers think about[/color]
> the[color=green]
> > idea. Are there any pitfalls that could result from this approach? I[/color]
> would[color=green]
> > hate to paint myself into a corner. Could I sub-class, via visual form
> > inheritence, a web user control and further enhanced as well?
> >
> > Looking forward to your feedback. Cheers.
> > --JQPDev
> >
> >[/color]
>
>[/color]

re: Technique??? Use a web user control to store & share data access component groups

BTW... How did you get MVP title?

re: Technique??? Use a web user control to store & share data access component groups

Hey... I have a lot of experience with DataModules (Delphi since 1.0). I
also used them quite a bit in the Delphi world. The equivalent (for me) is
to utilize web services and pass ADO.NET Dataset objects back-and-forth
between the web service and the front end(s). The ADO.NET DataSet object is
actually a container (just like the DataModule). You can drag and drop
multiple tables (which builds a DataTable object inside the DataSet object)
into a single DataSet. One way to look at it is thus:

DataModule = DataSet
TQuery/TTable = DataTable (visually dropped into a DataSet. optionally use
DataAdapter to populate/update)

One nice feature about the ADO.NET is that you can setup relationships
between tables with cascading updates/etc.

For stored procedures I use "pass through" web service calls (to the same
'class' that handles updates/reads/etc on my ADO.NET dataset tables). The
ADO.NET Dataset is serializable, therefore it passes directly to/from a
webservice...

Not sure how the rest of the world does this, but that is how I segregate
and use it. My ASP.NET webforms and/or WinForms only reference ADO.NET
Datasets (no native SQL connections/access in this layer, all done in web
service layer). Seems to work pretty good.

and I have also
"jqpdev" <jqpdev@counterattack.com> wrote in message
news:O7Q#JbN9DHA.2644@TK2MSFTNGP11.phx.gbl...[color=blue]
> Thanks Kevin for the update. I knew about Anders. Actually he was
> proprositioned by Microsoft a while back. You can call it a very sneaky[/color]
or[color=blue]
> a very smart move on the part of M$. Without Anders we wouldn't have
> VB.NET, or C#.net. VB.NET has the equivalent feature set of Delphi v4 and
> v5. The same could be said for C#.net in VS.NET 2003. Whidbey/dotnet 2.0
> will add some nice features. However, Borland has dotnet enabled all of
> their products. I jumped ship because I couldn't find readily available
> work in NYC with Delphi. There were some, but mostly scarce.
>
> ...and now back to my question. I'm saying that I was the only person to
> land on the idea of centralizing data access code & controls in web user
> controls. Can you give me some additional details on the pros and cons of
> this approach? I'm using VS.NET 2003 if that makes any difference.
>
>
> "Kevin Spencer" <kevin@takempis.com> wrote in message
> news:O0ojkTK9DHA.2404@TK2MSFTNGP12.phx.gbl...[color=green][color=darkred]
> > > So I came up with a nice idea of dropping data access controls on to a[/color][/color]
> web[color=green][color=darkred]
> > > user control to centralize the data access code and controls.[/color][/color][/color]
However,[color=blue]
> I[color=green]
> >
> > Surprise. You didn't come up with the idea in the first place. It[/color][/color]
already[color=blue][color=green]
> > exists in Visual Studio.Net. You might be interested ot know that Anders
> > Hejlsberg, one of the principal architects of Turbo Pascal and Delphi,[/color][/color]
was[color=blue][color=green]
> > one of the principal architects of the C# language.
> >
> > --
> > HTH,
> > Kevin Spencer
> > .Net Developer
> > Microsoft MVP
> > Big things are made up
> > of lots of little things.
> >
> >
> > "jqpdev" <jqpdev@counterattack.com> wrote in message
> > news:#1ciWlB9DHA.3404@TK2MSFTNGP09.phx.gbl...[color=darkred]
> > > Hello all...
> > >
> > > I'm coming from a Borland Delphi background. Delphi has a specific
> > > component called a Data Module. In the designer the Data Module[/color][/color][/color]
behaves[color=blue][color=green][color=darkred]
> > > like a windows form. A developer can drop non-visual (controls) on[/color][/color][/color]
the[color=blue][color=green]
> > data[color=darkred]
> > > module surface and wire them up and create procedures, functions,[/color][/color][/color]
event[color=blue][color=green][color=darkred]
> > > procedures. In the source file (code behind file) the Data Module is[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > class, and the dropped components are public properties. The event
> > > procedures/functions are public as well. The developer can add[/color][/color]
> additional[color=green][color=darkred]
> > > public/private/protected procedures, functions, and data members.[/color][/color][/color]
This[color=blue][color=green][color=darkred]
> > > module can be shared among several other modules within the project,[/color][/color][/color]
by[color=blue][color=green][color=darkred]
> > > using a syntax similar to using clause in C#.
> > >
> > > The benefits this provides is what I'm attempting to mimic in VS.NET[/color][/color]
> 2003.[color=green][color=darkred]
> > > If one is designing a single feature of an application, the feature[/color][/color]
> could[color=green][color=darkred]
> > > most likely be composed of several modules (source files and forms).[/color][/color]
> All[color=green]
> > of[color=darkred]
> > > the data access code and controls for the feature can be centralized[/color][/color][/color]
by[color=blue][color=green][color=darkred]
> > > placing it in a data module. All of the non-data access centric code[/color][/color]
> for[color=green][color=darkred]
> > > the feature, located in other modules, would talk the to the data[/color]
> > module(s)[color=darkred]
> > > created for the feature. Data modules even support sub-classing via[/color]
> > visual[color=darkred]
> > > inheritance.
> > >
> > > So I came up with a nice idea of dropping data access controls on to a[/color][/color]
> web[color=green][color=darkred]
> > > user control to centralize the data access code and controls.[/color][/color][/color]
However,[color=blue]
> I[color=green][color=darkred]
> > > wanted to know what other more experienced VS.NET developers think[/color][/color][/color]
about[color=blue][color=green]
> > the[color=darkred]
> > > idea. Are there any pitfalls that could result from this approach? I[/color]
> > would[color=darkred]
> > > hate to paint myself into a corner. Could I sub-class, via visual[/color][/color][/color]
form[color=blue][color=green][color=darkred]
> > > inheritence, a web user control and further enhanced as well?
> > >
> > > Looking forward to your feedback. Cheers.
> > > --JQPDev
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

re: Technique??? Use a web user control to store & share data access component groups

Jamie,

Thanks for responding. I also considered this approach as well. However,
I'm still experimenting with webservices and I'm still getting to know how
they Microsoft implements things. I think Borland has a cleaner approach to
building webservices, but then again that is a bias statement coming from
one who has a background in Borland's tools.

"Jamie Dulaney" <jdulaney@softwareexperts.net> wrote in message
news:%23beajuX$DHA.1732@TK2MSFTNGP12.phx.gbl...[color=blue]
> Hey... I have a lot of experience with DataModules (Delphi since 1.0). I
> also used them quite a bit in the Delphi world. The equivalent (for me)[/color]
is[color=blue]
> to utilize web services and pass ADO.NET Dataset objects back-and-forth
> between the web service and the front end(s). The ADO.NET DataSet object[/color]
is[color=blue]
> actually a container (just like the DataModule). You can drag and drop
> multiple tables (which builds a DataTable object inside the DataSet[/color]
object)[color=blue]
> into a single DataSet. One way to look at it is thus:
>
> DataModule = DataSet
> TQuery/TTable = DataTable (visually dropped into a DataSet. optionally use
> DataAdapter to populate/update)
>
> One nice feature about the ADO.NET is that you can setup relationships
> between tables with cascading updates/etc.
>
> For stored procedures I use "pass through" web service calls (to the same
> 'class' that handles updates/reads/etc on my ADO.NET dataset tables). The
> ADO.NET Dataset is serializable, therefore it passes directly to/from a
> webservice...
>
> Not sure how the rest of the world does this, but that is how I segregate
> and use it. My ASP.NET webforms and/or WinForms only reference ADO.NET
> Datasets (no native SQL connections/access in this layer, all done in web
> service layer). Seems to work pretty good.
>
> and I have also
> "jqpdev" <jqpdev@counterattack.com> wrote in message
> news:O7Q#JbN9DHA.2644@TK2MSFTNGP11.phx.gbl...[color=green]
> > Thanks Kevin for the update. I knew about Anders. Actually he was
> > proprositioned by Microsoft a while back. You can call it a very sneaky[/color]
> or[color=green]
> > a very smart move on the part of M$. Without Anders we wouldn't have
> > VB.NET, or C#.net. VB.NET has the equivalent feature set of Delphi v4[/color][/color]
and[color=blue][color=green]
> > v5. The same could be said for C#.net in VS.NET 2003. Whidbey/dotnet[/color][/color]
2.0[color=blue][color=green]
> > will add some nice features. However, Borland has dotnet enabled all of
> > their products. I jumped ship because I couldn't find readily available
> > work in NYC with Delphi. There were some, but mostly scarce.
> >
> > ...and now back to my question. I'm saying that I was the only person[/color][/color]
to[color=blue][color=green]
> > land on the idea of centralizing data access code & controls in web user
> > controls. Can you give me some additional details on the pros and cons[/color][/color]
of[color=blue][color=green]
> > this approach? I'm using VS.NET 2003 if that makes any difference.
> >
> >
> > "Kevin Spencer" <kevin@takempis.com> wrote in message
> > news:O0ojkTK9DHA.2404@TK2MSFTNGP12.phx.gbl...[color=darkred]
> > > > So I came up with a nice idea of dropping data access controls on to[/color][/color][/color]
a[color=blue][color=green]
> > web[color=darkred]
> > > > user control to centralize the data access code and controls.[/color][/color]
> However,[color=green]
> > I[color=darkred]
> > >
> > > Surprise. You didn't come up with the idea in the first place. It[/color][/color]
> already[color=green][color=darkred]
> > > exists in Visual Studio.Net. You might be interested ot know that[/color][/color][/color]
Anders[color=blue][color=green][color=darkred]
> > > Hejlsberg, one of the principal architects of Turbo Pascal and Delphi,[/color][/color]
> was[color=green][color=darkred]
> > > one of the principal architects of the C# language.
> > >
> > > --
> > > HTH,
> > > Kevin Spencer
> > > .Net Developer
> > > Microsoft MVP
> > > Big things are made up
> > > of lots of little things.
> > >
> > >
> > > "jqpdev" <jqpdev@counterattack.com> wrote in message
> > > news:#1ciWlB9DHA.3404@TK2MSFTNGP09.phx.gbl...
> > > > Hello all...
> > > >
> > > > I'm coming from a Borland Delphi background. Delphi has a specific
> > > > component called a Data Module. In the designer the Data Module[/color][/color]
> behaves[color=green][color=darkred]
> > > > like a windows form. A developer can drop non-visual (controls) on[/color][/color]
> the[color=green][color=darkred]
> > > data
> > > > module surface and wire them up and create procedures, functions,[/color][/color]
> event[color=green][color=darkred]
> > > > procedures. In the source file (code behind file) the Data Module[/color][/color][/color]
is[color=blue]
> a[color=green][color=darkred]
> > > > class, and the dropped components are public properties. The event
> > > > procedures/functions are public as well. The developer can add[/color]
> > additional[color=darkred]
> > > > public/private/protected procedures, functions, and data members.[/color][/color]
> This[color=green][color=darkred]
> > > > module can be shared among several other modules within the project,[/color][/color]
> by[color=green][color=darkred]
> > > > using a syntax similar to using clause in C#.
> > > >
> > > > The benefits this provides is what I'm attempting to mimic in VS.NET[/color]
> > 2003.[color=darkred]
> > > > If one is designing a single feature of an application, the feature[/color]
> > could[color=darkred]
> > > > most likely be composed of several modules (source files and forms).[/color]
> > All[color=darkred]
> > > of
> > > > the data access code and controls for the feature can be centralized[/color][/color]
> by[color=green][color=darkred]
> > > > placing it in a data module. All of the non-data access centric[/color][/color][/color]
code[color=blue][color=green]
> > for[color=darkred]
> > > > the feature, located in other modules, would talk the to the data
> > > module(s)
> > > > created for the feature. Data modules even support sub-classing via
> > > visual
> > > > inheritance.
> > > >
> > > > So I came up with a nice idea of dropping data access controls on to[/color][/color][/color]
a[color=blue][color=green]
> > web[color=darkred]
> > > > user control to centralize the data access code and controls.[/color][/color]
> However,[color=green]
> > I[color=darkred]
> > > > wanted to know what other more experienced VS.NET developers think[/color][/color]
> about[color=green][color=darkred]
> > > the
> > > > idea. Are there any pitfalls that could result from this approach?[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> > > would
> > > > hate to paint myself into a corner. Could I sub-class, via visual[/color][/color]
> form[color=green][color=darkred]
> > > > inheritence, a web user control and further enhanced as well?
> > > >
> > > > Looking forward to your feedback. Cheers.
> > > > --JQPDev
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]