Data Layer: Module vs. Class w/Static Methods

[Phillip Ian]

Just a quick architecture question. I'm just looking for discussion,
not a flame war, please.

In the past, I've tended to use a public module for my data layer
functions. Something like:

public module db
Friend ConnectionString As String = ""

Public Sub InitializeDB(ByVal AConnectionString As String)
ConnectionString = AConnectionString
End Sub

public function GetUserRecord(AnID as integer) as cUser
...
end function

public function GetUserList as cUserList
...
end function
end module

Now, with the new object data source, it looks to me like the framework
is expecting a class, not a module.

public class db
public shared function GetUserRecord(AnID as integer) as cUser
...
end function

public shared function GetUserList as cUserList
...
end function
end class

That's fine, I can live with it. I'm just curious why the requirement
that the data access functions be methods instead of just functions.

I'm also assuming that the preferred way of handling the connection
string would be in the ConnectionStrings element of the app.config
file?

Anyway, hopefully someone can tell me if I'm heading down the wrong
path here, before I go changing my whole methodology.

 

[Phillip Ian]

See, I know I'm already all confused. There is no app.config file in
the data layer class library. My only excuse is that I don't wake up
until noon.

So I'm still going to need some storage somewhere in the data layer for
the connection string. Two options I can see:

1) Make the methods unshared (non-static?) so that the object data
source will have to instatiate my class. Pass the connection string
into the constructor.

2) Put my module back, just for the sake of holding the connection
string. At least with this option I can access the connection string
anywhere in the class library. But then again, that tempts me to mix
data access logic into my business entities.

Ok, I lied...option 3: Forget I ever read about data access layer
components. I understand their advantages, but man they seem to
create more questions than they avoid!

 

[Karl Seguin]

i'm pretty sure the clr doesn't support the concept of modules. VB.Net
simply turns a "module" into a sealed class and all members are made static.

In other words, i'm almost convienced that there's no difference between
your two examples.

The only thing which MIGHT be different, is that modules might be
MustInherit (sealed) which i guess could be screwing around with the
objectdata source.

Karl

 

[Kevin Spencer]

The following MSDN .Net SDK article may be of help:

http://msdn.microsoft.com/library/d...7/html/vbconclassmodulesvsstandardmodules.asp

Modules are one of the bones thrown to developers migrating from VB6 to
VB.Net. If one understands how they work, they can be just as useful as
(although not moreso than) classes containing all static method, properties,
and fields.

That said, however, it is important to note that while VB.Net LOOKS like
VB6, it is not by any stretch of the imagination the next version of VB, or
VB7. It is an implementation of the VB language for the .Net platform. The
..Net platform is fully object-oriented. These differences are not trivial.

Therefore, I would recommend avoiding the use of VB.Net Modules, as they
provide no accessibilty control whatsoever to their members. They break
encapsulation, a vital pillar of object-oriented programming. And as a class
with static members can do everything that a Module can do, it would seem
(IMHO) better to use a class and explicitly declare what can and cannot be
accessed in what capacity by other classes. I have seen (and had to
research, run down, and correct) the misuse of Modules enough to have some
expertise about this.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.