Help to change from Classic VB to VB .Net

[nasreen]

I am using Classic VB 6.0 for last 10 years and I am very pretty with this language.

For last 6 months I am trying to learn .Net languages to develop my new projects in VB .Net or C#. Actually I have read many books, sources about these languages and got an overall idea about coding, winforms, OOPs, advantages of .Net framework, etc. I understand all examples given in books and I do these examples and sample codes perfectly.

Now the problem I face is I can't start a project using VB .Net or C#. Whenever I think about a project my mind directly goes to the classic system, ie. procedure oriented programming that I am familiar with for a long time in VB 6. I don't know how to start a project in VB .Net, from where I could begin an OOP coding and how I can do a project in OOP.

So anybody can recommend me any step by step guidelines to start a project in .Net languages

[jmcilhinney]

First things first, with 105 posts it should not be necessary for us to tell you that questions don't belong in the CodeBank forums. I have asked the mods to move this thread to the VB.NET forum.

As for the question, most beginners don't really use OOP much beyond the fact that they use the classes built into the .NET Framework. All the code they write in the forms is rather procedure-based. They simply handle events of their controls and put their code in those methods. All data access gets done there and so one. Even most enterprise-grade apps don't really use OOP to the fullest extent, as it was originally intended.

If you want to think in OOP then you need to think in objects, so the first step is to consider what entities you need to represent in your application. Those entities may be physical, e.g. users or stock items, or they may be abstract. The key to good OOP is identifying and representing the abstract entities. Consider how data access is performed in VB6. In ADO you have the Recordset and that basically does everything. In VB.NET you should use ADO.NET for data access. In that case you have one class to represent the connection to the database, one to represent a command containing SQL code to execute, one to represent a parameter that contains data to be used in a command, one to group the four most common operations you might perform (SELECT, INSERT, UPDATE & DELETE) so that you can easily move data between a table in the database and your app and back again, one to represent a table of data stored locally, one to represent multiple tables stored locally and the relations between them, one to represent one of those relations and so on. Each of those classes has a specific job to do and it concentrates on doing that job. To perform data access you have lots of specialised objects working together, each doing their job to accomplish the whole. That's the sort of model you need to use.

So, start by considering high-level entities, first the physical and then abstract. Consider what more specialised entities these might make use of and how they might interact to perform the required task. You're not going to get it completely right from the word go and you'll no doubt look back in a few months at code you write now and wonder what you were thinking, but that's the learning process we all go through.

[si_the_geek]

Thread moved from the 'CodeBank VB.Net' forum (which is for you to post working code examples, not questions) to the 'VB.Net' forum