New to VB.Net; Struggling with Architecture...

[Johnny Meredith]

Hi,

I'm relaively new to programming languages in general, and brand
new to VB.NET. I use/used VBA in MS Access previously to do what
I needed. I want to learn VB.NET to stretch my boundaries a bit.

Anyway, I'm developing an application to track the progress of
tax audits. Originally, I thought I would write objects something
like this:

Public MustInherit Class Document...
<<<abstract class for all document types>>>
Public Class IDR
inherits Document
<<<an IDR document>>>

etc.

All docs inherit from a single base class. Docs expose properties
like Number, Description, etc. Methods are Add, Update, Delete.
There would be a non-default constructor exposed to instantiate a
document that already exists in the datasource, something like...

Public Sub New(Byval value as Integer)

where value is the key used in a search of the table for the doc.

These were my original thoughts. Now that I know alot more about
strongly typed datasets, I wonder if it's even worth the effort to
manually create these objects (especially give the ability to bind
forms to data adapters) Or, as a compromise, should the
object expose a dataset/adapter itself as a property? At that
point, the ojbect is really just an advanced controller for the
exposed dataset I think.

I think I'm mixing concepts here, but I have not read enough to
understand where I'm screwing up. Does anyone understand my delimma?

Thanks,
Johnny

[Cor Ligthert]

Johnny,

See inline

I'm relaively new to programming languages in general, and brand
new to VB.NET. I use/used VBA in MS Access previously to do what
I needed. I want to learn VB.NET to stretch my boundaries a bit.
Keep in mint that using VBNet is different from VBA and don't try to make
them equal.
The benefit is that you know some general behaviour from VB as the way you
do an "If" and the operators.

Anyway, I'm developing an application to track the progress of
tax audits. Originally, I thought I would write objects something
like this:

Public MustInherit Class Document...
<<<abstract class for all document types>>>
Public Class IDR
inherits Document
<<<an IDR document>>>

The documents are the hardest classes to do, so I would certainly not begin
with those.
These were my original thoughts. Now that I know alot more about
strongly typed datasets, I wonder if it's even worth the effort to
manually create these objects (especially give the ability to bind
forms to data adapters) Or, as a compromise, should the
object expose a dataset/adapter itself as a property? At that
point, the ojbect is really just an advanced controller for the
exposed dataset I think.

I think I'm mixing concepts here, but I have not read enough to
understand where I'm screwing up. Does anyone understand my delimma?

Just start with the way it is documented. Problem is that it is one time
with a strongly typed dataset using the designer and than in an other
situation with direct the objects instanced from system.data.

Keep in mind that the use of classes and the good documentation of that is
as well related from the organisation where you are making programs in. When
you are alone it needs a complete different approach than when you are
developing with more than 3 person on one application.

Just my thought,

Cor

[SimonH]

I cant answer your specific question, but in terms of architecture in general,
I really found using reference applications very helpful.

In particular is the CommunityForums source code from telligent systems.
Its a really solid application that actually works really well, is well programmed
and is pretty - something that most other reference applications are missing.

Also the Windows Forms reference application from Infragistics to show off
their controls was really good, especially given the ebook that you can download
discussing the architecture.

Then you've got the reference applications at www.asp.net. - Bear in mind
that the logic layers from asp.net applications are often very similar to
those of Windows Forms applications. The same is true of the data access
layer in most cases.

The other general piece of advice I would give is to not try and make the
perfect design. I remember spending ages trying to find where I could use
inheritance and in all actuallity there are relatively few places where it
should be used. There are often better ways of approaching a problem than
inheritance anyway.

I really would recommend looking at the Community Forums application though.
If you leave the UI project to one side you really should be able to get
some ideas that you like.

The reason I say "that you like" is because really thats what it comes down
to. I looked at just about every reference application in the hope that I
would find "The" architecture - the fact of the matter is, there is no one
application that comes close to getting it all perfect - but then again thats
just my opinion. Just don't make my mistake and think that you can't mix
and match approaches from different applications and samples.

Thanks

Simo

[Johnny Meredith]

SimonH,

Thank you very much for the insights. It's nice to know that someone
else out there has
experienced the same thing I have. I just have one more question for
you/all: what do you
think about the idea of exposing a dataset and/or adapter as a
property? Have you ever
done this? Is it stable? Do you use databound forms and controls?

Thanks,
Johnny