WPF Applications/Database - Total Beginner

I am new to object oriented programming and application development.  I have seen lots of books detailing WPF or VB.Net or SQL Server but there doesn't seem to be anything combining these elements, providing practical examples of how to build an application/database.  My only experience of code is VBA and a little HTML/CSS/Javascript.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Norman MainaCommented:
Microsoft "How Do I" video series are a good start.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
David L. HansenProgrammer AnalystCommented:
I'd like to help with the object-oriented question.  It is a concept that is often made harder than it needs to be.  If you'd like to hear my mini-lecture on the topic, just say so.
DamozzAuthor Commented:
That would be good.  Thanks
David L. HansenProgrammer AnalystCommented:
It used to be that programmers would have an idea in mind for what their interface (GUI) would look like to the user.  They would then approach programming from that point of view (what do I need to code to get that button to work right, or the grid will have x, y, and z info, so I'll grab that from the database and fill the grid, etc.).  This happened without much though as to how these decisions would affect the program as a whole.  As programs became bigger and bigger, and more and more complex, that approach eventually broke down.  The same queries would be found scattered all over in the code.  During later maintenance, nobody (including the original author/authors) knew where they were in the code a few moths after writing it, and so on.  So objects became the new point-of-view for programming.  

I'm going to throw in a personal experience which may help here.  I toured a car manufacturing facility back in the early 90's and observed that although an assembly line was being used, it was not a typical one; each station along the path would perform different tasks based on the car that came through - yes, the assembly line had a mixture of car types on the same line!  Robots did most of the work.  Consider, each car had an electronic canister attached that told the robots everything about that specific car (model, color, accessories, and perhaps other buyer's decisions) so the robots knew just what to do.  That is what we are doing now.  Our (your) routines are like the robots and the information you are dealing with are the objects.  You make the object (like the information canister) and pass it around through your program dealing with it and responding to it appropriately.

You might make a custom 'bike' class.  Now, at this level you'll want to keep that class pretty sparse (not intuitive is it - but I'll explain).  If you will be dealing with race bikes, mountain bikes, touring bikes, etc. then the bits of information about those bikes that are specific to them go in their OWN classes (ie, Class_Moutain_Bike) and they would each INHERIT from the more general bike class.  So, the bike class may have: Serial_Number, Frame_Type, Wheel_Type, Color, and so on...very general.  Although the mountain_bike class would still have all the stuff in the general bike class (because of inheritance) it will also have things like Shocks, or specialized gearing.  Those things don't belong in the bike class - it's too specific.

So your program creates bikes (using the different bike classes to create bike-objects) which get passed around your program getting adjusted and/or simply sharing its information.  At the end of the day, your program looks sort of like that car manufacturing plant - you don't see data or processes that say "hey, I deal with the data belonging to that one model during that period of time."  Instead you see flexible processes that can deal with a lot of different objects and scenarios.  So data complexities are contained in the objects and process complexities are contained in the routines.  Need to start a new line of bikes? - just inherit from the bike class and off you go.  Need to implement a new billing process? - just build the processes and pass the same old bike objects into them.

Objects have improved our programming lives and although it is powerful, it isn't perfect. However, once you understand it's strengths you can leverage them to make your programs easier to build and maintain.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.