Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Lessons Learned in Enterprise Design and VB6

In this article you will be presented with a number of tips taken from lessons that the author has learned after a couple of years working with COM+, VB6 and SQL Server.


advertisement
t’s now been more than two years since I wrote the article "18 Common Programming Traps in MTS." The article was great fun to write, and I received, and in fact am still receiving, a lot of positive feedback from readers. I wrote the article after having worked with MTS, VB6 and SQL Server for quite a while, and yet I have learned a lot since then, so in this article I’ll be discussing some of the lessons I have learned most recently.

Most of the tips come from my real-world projects, but there is another source too.

<shamelessPlug>
I developed some of the tips while writing my book .NET Enterprise Design with Visual Basic .NET and SQL Server 2000. Even though the book is about Visual Basic .NET, some of the ideas can be downgraded to VB6 and we can benefit from them here too. Most of the tips, presented only briefly here, are discussed in depth in the book.
</shamelessPlug>



Without further ado, let’s get started.

Lesson Learned #1: Using Shared Methods
For years I’ve regarded the usage of modules (.BAS) in VB6 as not being purely object oriented. Nevertheless, I have used modules a lot especially for helpers. Now, having worked a lot with Visual Basic .NET and its Shared methods, modules in VB6 do in fact feel very object oriented! If you call a sub in a module in VB6 this is how it could look if you prefix with the module name:

MyModule.DoStuff

If you call a Shared method in Visual Basic .NET, it could look like this:

MyClass.DoStuff(42)

Shared methods and VB6-modules are more or less the same thing. For instance:

  • You don’t need to do any instantiation before using them.
  • You have to take care when using module-level/Shared data.
  • You don’t get any context or interception overhead for COM+ when using them.
  • You don’t have to worry about cleaning up of instances.

I really like the idea of using Shared methods for my secondary COM+ layers in Visual Basic .NET. That is, the layer called by the client (named the Application layer in my architecture) will be built with ordinary classes that are instantiated and have members. However, the later layers, those used by the Application layer classes, will often be built with Shared methods. These layers are completely stateless anyway, and then Shared methods are a very good solution.

When I came to the insights above, I decided to favour modules for my later layers in VB6 too. The drawbacks with using Shared methods/modules for the later layers as proposed here are as follows: You can’t use user-defined interfaces for getting consistent code and flexibility is lost because you can’t move a module to another COM+ application and call it directly from the Application layer in the first COM+ application. Apart from these, there are more advantages than disadvantages, for example, efficiency.

#2: Stored Procedures as the Only Way to Access the Database
The way to access SQL Server is by using stored procedures, which present numerous advantages, such as:

  • Efficiency
  • Resource-savings
  • Fewer roundtrips
  • A small entry point to the database
  • A better mechanism for security
  • Efficiency (just in case you missed it before)
  • Etc

The only commonly referred-to drawback is the lack of portability in stored procedures between database platforms. This may be true, but in a way I think using stored procedures can actually help portability, as all your database code is put in one single place. I recently reviewed some code from a project where they had decided not to use stored procedures due to what they considered the portability problem. On the other hand, they had scattered PL-SQL (Oracle’s dialect) code all around the VB-code which is not easier to port, believe me!

I’ve been a fan of stored procedures since early 1990, but it’s not been so many years since I decided to use only stored procedures for communicating with the database. Now this is completely natural. Some things are a bit clumsy (such as sending arguments for IN-clauses), but still doable.





Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date