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

[jqpdev]

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

 

[Kevin Spencer]

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

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]

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.

 

[jqpdev]

BTW... How did you get MVP title?

 

[Jamie Dulaney]

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]

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.