Visual Studio / Visual Basic / dotNET

[rberq]

This is not an ME question, but I know some of you do a lot more than write macros.

 

Can anyone recommend a good book or other resource for getting up to speed with Visual Studio / Visual Basic / .NET programming? I am NOT interested in the typical 1500 page book that tells me every mouse click and wrist movement to drag controls onto forms and display "Hello, World" in a message box. What I need is more of a technical understanding of how projects are structured internally, how they interact with Windows and with SQL databases and file systems, what those <weird strings of words in brackets> are all about, how to package procedures in a DLL as opposed to an EXE, how to integrate a VB program with one in some other language like C++, and so on. I come from a long background in procedural language programming (IBM Assembler, COBOL, RPG), where you could pick up a book and understand how your program interacts with the operating system. But I am having trouble getting my arms around object oriented programming and the fact that Microsoft invents a new programming architecture about every 18 months.

 

Thanks for any sources you can recommend.

[Cory]

I found "Sams Teach Yourself Visual Basic 2008(2010 now) in 24 Hours" a fairly good read. I don't think it’s exactly what you're asking for because I too was looking for something similar but none seems to exist. This book does have you doing things and making apps using things you do not yet understand which is contrary to the way I like to learn but if you plow ahead he does eventually discuss what's happening and the theory. I also use MS's Visual Basic 2010 Developer's Handbook. Let me know if you find something better.

 

BTW I came from a background of procedural programming with languages like Pascal so I am making the same mental adjustment. But IMHO OOP really is procedural at its core. It’s just that they hide blocks of procedures in these things called objects. It’s more just a uniform way of interacting with these blocks and .NET is just a huge library of ready made code one gets to tap into. Anyway it helped me to think of them this way. And instead of having a line for every operation you embed several things into one line and this often avoids the need for variables. However I often find that things I could crunch into a single line I blow out into several just to make it easier to read.

[rberq]

Thank you, Cory. I used a SAMS book for SQL and it was good. I will get both the books you recommend.

 

Like you I have tried to make sense of OOP in terms of the older programming methods, and I agree, it is similar functionality except with a different wrapper. The most useful advice I have received on the subject of OOP is, "Don't over-think it".

[paul]

But IMHO OOP really is procedural at its core. It’s just that they hide blocks of procedures in these things called objects. It’s more just a uniform way of interacting with these blocks and .NET is just a huge library of ready made code one gets to tap into.

I don't think I agree with this.

 

Consider a procedural method of processing customers, where one simply starts at the top and plods through the code, dealing with customers according to their needs, restarting at the top for each new customer. Conceptually, a customer is represented by fields in one or more tables, and processed by any number of functions, e.g. add, modify, delete, report, archive.

 

Now consider an OO system where one might very easily decide to create a new customer object instance, perhaps asynchronously, for each of several customers due for processing. Now that seems to me an entirely different model. Conceptually, a customer is represented by its object instance, therefore appearing as a black box to the outside world, with selected methods and attributes made public as the designer sees fit, e.g. add, modify, etc.

[Cory]

You are correct of course. Sort of. But in the black box is essentially procedure. When it comes right down to it machine code is procedural and OOP is an abstraction. For instance if you create an object with a properly of color the value "Blue" doesn't exist until the code is executed demanding that property. In fact if there's a problem determining that color you will not find out until it's called. OO is an abstraction. But it is best if one can think of them as objects but I found it helpful to realize it OO is an abstraction to dispel the magic and make it real in my mind. It's all paradigms. And no paradigm is 100% accurate. Just different levels of functionality which are more or less useful depending on your skill level. I still often think of electricity with the hydraulic theory analog. Works on my car at least. At least until I use a low power digital meter to test to diode