Design & Coding practices for VB.NET

[Gila47ac]

Hello all,

The shop I'm in is using VB6, but is starting to use VB.NET.

What design practices - specific to .NET - do you recommend to ensure good maintainability? Performance? Security?

And what coding practices would you recommend - specific to VB.NET? (I see that someone recommends reading Coding Techniques for MS Visual Basic.net .)

I'm considering modifications to the development standards we have.

 

[JohnYingling]

Option Strict On
' Absolute rule.

http://www.VBResizer.com

Forms/Controls Resizing/Tabbing

http://www.VBCompare.com

Compare Code

http://www.VBSortGen.com

Generate Sort Class in VB

http://www.Vbcompare.com/Check.Htm(1979

Check To MS)

 

[ThatRickGuy]

Object Oriented design is a huge step up. It's not always the top for performance, but the man hours saved in development and maintenance will more then make up for it. And proper object design can keep any performance hit to a minimal level.

The other thing I harp on is data abstraction. Binding data to the GUI is evil. It will give you many more headaches then what it's worth. Create data abstraction objects to take care of all of the data interaction. Expecially on large scale applications, creating a set of objects to handle all of your data interactions can make the job so much easier.

-Rick

----------------------

http://www.ringdev.com

 

[RiverGuy]

I still kindly disagree with Rick. I won't go out and say that databinding is evil. In my opinion, ADO.Net is already somewhat abstract with its disconnected architecture, and objects that represent what is in your database. I will say that I do dislike databinding with ADO in VB 6.

I will say, however, that since ADO.Net is completely different from ADO, you will need to adjust to this and be sure your code does not become sloppy.

 

[ThatRickGuy]

Databinding in and of itself is not bad. It's binding data to the GUI that is 'teh debil' (evil). By binding data to the GUI it is by definition, not abstract.

-Rick

----------------------

http://www.ringdev.com

 

[RiverGuy]

I still disagree. I want to make sure Gila gets both sides of everything. As far as abstraction--I was referring to it in terms of the database itself...since the database is not worked with directly until a .Fill or .Update or .ExecuteNonQuery, etc.

I think the summary is that there always MAY be negatives to databinding to the UI, which is the side you take. And the other side is that databinding to the UI is much more different in VB.Net that I feel it can be beneficial.

 

[chiph]

I vote with Rick -

People new to VB.NET will be well served by learning O-O design techniques.

My personal opinion is also that databinding is generally bad. Although it does have it's place in prototypes and one-off programs, I don't think it has any place in a production-quality application.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[chrissie1]

Let's make it 2 all I go wiith Riverguy. As long as you don't abuse it then it's ok. My datatables never have more then one record in them (Yes I know pro's and con's) (or the least possible, paging) And I don't do my binding via the gui (all via code) So I keep control. And yes I used to hate databinding aswell untill I got to know it better.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[ThatRickGuy]

The major issue I have with binding data is control. With ADO.Net things have improved, bound data in ADO.Net is significantly more flexable then it ever was in ADO. And the OO nature of .Net allows for inheritance and building from the base ADO.Net objects. Unfortunatly, data bound GUI controls in my experience, still have many shortfalls. Many of those shortfalls can be circumvented just by using a data abstraction object to make a layer between your data actions and your gui actions.
This also leads to more flexability, one app I'm working with connects to a vendor's database. Every once and a while they like to change field names and what not. Our data abstraction layer can pick up the slack and we won't even have to redeploy to cope with the new data structure.
We also have a huge amount of reusability. We have a Data Objects DLL (a collection of our data abstraction objects) that gets referenced by 6 different apps. In each of these apps there is no sql, no data sets, no data interaction. They work exclusively with a set of Business Objects. This allows us to use the Buisness Objects (which all inherit from a base business object) like an API set. We can throw together reports, merge letters, data tracking/modding apps, etc in a matter of a few hours because all of the data work is done.

-Rick

----------------------

http://www.ringdev.com