VB.Net / MS Access Analogy. (1 Viewer)

[Uncle Gizmo]

I am just watching VB.net --- Lesson 6: (part two) Object Oriented Programming Fundamentals --- From --- Learning Resources for Visual Basic Express link posted in another thread ---

from the explanation of How a class works, and in particular the "constructor"

I think an MS Access programmer could benefit from thinking of it like this. An MS Access form is actually based on a class, everything you can do within a form is controlled, by the form class.

In the form you have the "load event" I think this is equivalent to the "constructor" event in a standalone class. It is where you would set the default values for the form, and also the default values for the class.

 

[Banana]

Yeah. One biggest benefit I can think of is that you could use a class to create a template form then all you need to do is tie up the data binding. Never have to reinvent the forms when you start on the new database.

This would be useful for complex forms using cascading comboboxes or need to do several data validation. Just drop it in, set the variable value to what you need for this form, and you're done.

I sure wish MS would move Access from VBA to VB .NET....

 

[WindSailor]

This is where I definitely need to spend more time in.

A while back I asked if Access would ever be a front-end for .net database applications and the reply was why would I want every Access user to have or need the knowledge of .net.
That would require a huge learning curve of relational database theory and .net.
So I don't think Access will ever make that jump. Big assumption on my part...

Another thing comes to mind, I don't believe any of Microsoft's applications are 100% managed code...

Now whether or not in the future Office / Access will totally support VBA / .Net together who knows...?

 

[WindSailor]

I have read ‘a little’ on OOP, but honestly never really practiced it. Everything catches up with you sooner or later… <g> it’s not like I don’t have enough to learn already.
I have always thought that when I got into OOP, I would use it something similar to how I used modules within forms in the past with Access. The only part that worried me about code jumping around in multiple layers was correctly trapping errors, is there anything special I should know?

What level should one take in practicing OOP with a relational database design, limitations?

Is an OO designed database the same as a relational database design?

Any additional information and links appreciated…

Thanks

 

[Kodo]

You have to organize your code files into sections. In the IDE (and more specificially in the solution) you can place folders to organize types of code bases you're working with like Interfaces, Enums, Utility classes and other business objects.

The IDE will help you track objects as it fully understands what each object is and can reflect upon it to deduce it's methods, properties etc. Also the object browser is a big help with namespaces/classes that you're not familiar with.

On Constructors:
Constructors are just that.. they help construct an instance of an object. Lets say you have a person object that needs to have a first name and last name set before the object is fully instantiated. It makes no sense to have a person object with no first name or last name just floating around out there so a constructor is one of insuring that the object gets created with required data that validates the objects existence.

The page_load event or form_load event are not constructors. They are sub routines (in VB) or voids (in C#).

.NET is a fairly large shift from VBA/VB6 and I would expect several months to ramp up.