I recently have inherited a rather large converted code base ( vb6 -> vb.net ) and am trying to come to grips with the use of 'modules'.
First, my application is a windows forms application, with this said, are there 'best practices' that I could use as a reference?
The real concern that I have is I have run into a massive 'utility' like module that holds a great deal of things ( user credentials, random methods, connection strings, ect ), making all of it available throughout the application. Is this normal in windows forms? The majority of my experience is in web applications and do not recall experiencing something like this before...
I am kind of lost as to make this heap of code more manageable so it can be digested and used properly. I am not opposed to the module itself, but I personally am leaning toward breaking some of this functionality into classes ( User class, DataAccess class, ect ) BUT, I want to give what VB.net has to offer a fair shake before doing so. At the least, I could break the module into a few modules with a more specific direction but I don't see the benefit of not breaking them into classes ( I have read .net creates a class from the module... ).
Re: Help understanding VB ( conversion & philosophy )
Modules were used quite heavily in VB6 and older versions even more so but are used little if at all in most .net applications.
I would break the module into classes where possible.
Converted code is often less than ideal and in most cases will benefit from being updated to newer methods and removing any dependancy on outdated runtime and com componets that can be carried over during conversion.
After converting a couple of projects myself I ended up rewriting them with the end result containing no modules.