Hello.
I'm trying to find another way to share an instance of an object with other
classes.
I started by passing the instance to the other class's constructor, like this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
45  2955 
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Hello.
I'm trying to find another way to share an instance of an object with other
classes.
I started by passing the instance to the other class's constructor, like this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
First of all, it is usually a bad idea to allow other classes, included sub
classes direct access to instance variables. It should always be through
properties. In fact, I try to never access field data even inside my own
class without going through properties :) The main reason is that properties
provide a layer of abstraction, that allows the implmentation change without
having affecting client code... For instance, what if a field needs to
become a calculated value? If you went through the property, all is well, but
if you allowed client code to directly access the field then you are in
trouble. Believe me, I have learned this lesson the hard way :)
That said... Let's see if we can't come up with a good answer, to your
problem :) Based off of what I'm seeing here, I don't see the problem with
your first example? Why do you feel it is better not to pass the parameter to
the constructor - though, I would probably do it more like this:
Class clsData
Private _sqlClient As clsSqlClient
private _users As clsUsers
Public Sub New (....)
SqlClient = new clsSqlClient(....)
Users = New clsUsers (SqlClient)
End Sub
Private Property Users As clsUsers
Get
Return _users
End Get
Set (ByVal Value As clsUsers)
_users = Value
End Set
End Property
Private Property SqlClient As clsSqlClient
Get
Return _sqlClient
End Get
Set (ByVal Value As SqlClient)
_sqlClient = Value
End Set
End Property
End Class
Anyway, that's my oppinion, others may differ. And it maybe another approach
my be better if you application has a different achitecture. Like, do all
isntances of all classes use the same SqlClient instance, etc.
--
Tom Shelton
Hi, Tom.
Thanks for your response.
Yes, multiple classes share a single instance of clsSQLClient connected to
the server. Right now, I'm passing it as a parameter to each of the class's
constructors.
ClsData is intended to wrap all of the data access functions of the
application.
ClsSQLClient Imports System.Data.SqlClient, and is the only class to do so.
ClsUsers has a 'has-a' relationship with clsData: the data object includes a
representation of the users table in the database.
I'm trying to figure out how to share an instance of a variable without
using inheritance. For a 'has-a' relationship (composition,) I've read
you're supposed to use interfaces instead of inheritance, but interfaces
don't contain implementation, so you can't share instances of objects at
runtime.
Maybe what I'm doing is what I'm 'supposed' to be doing, but I don't like my
class diagram having all these other classes point to my clsSQLClient.
I only want clsData to point to it, and all the other classes to point to
clsData.
When I tried to use inheritance, I got a nicer diagram, but broke the app.
Also, I'm not sure what you're referring to when you say it's:
a bad idea to allow other classes, included sub classes direct access to
instance variables
I didn't think I was allowing direct access to the private instance
variables outside of the classes. I agree, it's a bad idea, but I'm not
seeing where I'm doing it.
Thanks again for your response. I'm sticking with the parameters for now.
-Beth
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Hello.
I'm trying to find another way to share an instance of an object with other
classes.
I started by passing the instance to the other class's constructor, like this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
First of all, it is usually a bad idea to allow other classes, included sub
classes direct access to instance variables. It should always be through
properties. In fact, I try to never access field data even inside my own
class without going through properties :) The main reason is that properties
provide a layer of abstraction, that allows the implmentation change without
having affecting client code... For instance, what if a field needs to
become a calculated value? If you went through the property, all is well, but
if you allowed client code to directly access the field then you are in
trouble. Believe me, I have learned this lesson the hard way :)
That said... Let's see if we can't come up with a good answer, to your
problem :) Based off of what I'm seeing here, I don't see the problem with
your first example? Why do you feel it is better not to pass the parameter to
the constructor - though, I would probably do it more like this:
Class clsData
Private _sqlClient As clsSqlClient
private _users As clsUsers
Public Sub New (....)
SqlClient = new clsSqlClient(....)
Users = New clsUsers (SqlClient)
End Sub
Private Property Users As clsUsers
Get
Return _users
End Get
Set (ByVal Value As clsUsers)
_users = Value
End Set
End Property
Private Property SqlClient As clsSqlClient
Get
Return _sqlClient
End Get
Set (ByVal Value As SqlClient)
_sqlClient = Value
End Set
End Property
End Class
Anyway, that's my oppinion, others may differ. And it maybe another approach
my be better if you application has a different achitecture. Like, do all
isntances of all classes use the same SqlClient instance, etc.
--
Tom Shelton
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that code
is doing. I might have in 1999.
................
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Hi, Tom.
Thanks for your response.
Yes, multiple classes share a single instance of clsSQLClient connected to
the server. Right now, I'm passing it as a parameter to each of the class's
constructors.
ClsData is intended to wrap all of the data access functions of the
application.
ClsSQLClient Imports System.Data.SqlClient, and is the only class to do so.
ClsUsers has a 'has-a' relationship with clsData: the data object includes a
representation of the users table in the database.
Hmmm... Sounds to me like you need something along the lines of a
singleton...
Class clsData
Private Shared _instance As New clsData
....
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Class User
...
Public Sub SomeSub()
clsData.Instance.DoCoolStuff()
End Sub
End Class
<snip>
Also, I'm not sure what you're referring to when you say it's:
a bad idea to allow other classes, included sub classes direct access to
instance variables
I didn't think I was allowing direct access to the private instance
variables outside of the classes. I agree, it's a bad idea, but I'm not
seeing where I'm doing it.
Your probably not :) I didn't look that close, but I was just commenting on
your remark about allowing clsUsers direct access to the instance variable.
Thanks again for your response. I'm sticking with the parameters for now.
-Beth
--
Tom Shelton
On 2008-10-29, sloan <sl***@ipass.netwrote:
>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that code
is doing. I might have in 1999.
...............
Yep... I have to agree.
--
Tom Shelton
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is created
during the declaration instead of outside the class, enforcing the single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to the
base class instance in memory, so you could call the base class's functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class has its
own instance of myBase separate from any other instance, which makes sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before, but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Hi, Tom.
Thanks for your response.
Yes, multiple classes share a single instance of clsSQLClient connected to
the server. Right now, I'm passing it as a parameter to each of the class's
constructors.
ClsData is intended to wrap all of the data access functions of the
application.
ClsSQLClient Imports System.Data.SqlClient, and is the only class to do so.
ClsUsers has a 'has-a' relationship with clsData: the data object includes a
representation of the users table in the database.
Hmmm... Sounds to me like you need something along the lines of a
singleton...
Class clsData
Private Shared _instance As New clsData
....
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Class User
...
Public Sub SomeSub()
clsData.Instance.DoCoolStuff()
End Sub
End Class
<snip>
Also, I'm not sure what you're referring to when you say it's:
a bad idea to allow other classes, included sub classes direct access to
instance variables
I didn't think I was allowing direct access to the private instance
variables outside of the classes. I agree, it's a bad idea, but I'm not
seeing where I'm doing it.
Your probably not :) I didn't look that close, but I was just commenting on
your remark about allowing clsUsers direct access to the instance variable.
Thanks again for your response. I'm sticking with the parameters for now.
-Beth
--
Tom Shelton
but you can't listen for events from a singleton...
"Beth" wrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is created
during the declaration instead of outside the class, enforcing the single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to the
base class instance in memory, so you could call the base class's functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class has its
own instance of myBase separate from any other instance, which makes sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before, but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Hi, Tom.
Thanks for your response.
>
Yes, multiple classes share a single instance of clsSQLClient connected to
the server. Right now, I'm passing it as a parameter to each of the class's
constructors.
>
ClsData is intended to wrap all of the data access functions of the
application.
ClsSQLClient Imports System.Data.SqlClient, and is the only class to do so.
ClsUsers has a 'has-a' relationship with clsData: the data object includes a
representation of the users table in the database.
>
Hmmm... Sounds to me like you need something along the lines of a
singleton...
Class clsData
Private Shared _instance As New clsData
....
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Class User
...
Public Sub SomeSub()
clsData.Instance.DoCoolStuff()
End Sub
End Class
<snip>
Also, I'm not sure what you're referring to when you say it's:
a bad idea to allow other classes, included sub classes direct access to
instance variables
>
I didn't think I was allowing direct access to the private instance
variables outside of the classes. I agree, it's a bad idea, but I'm not
seeing where I'm doing it.
>
Your probably not :) I didn't look that close, but I was just commenting on
your remark about allowing clsUsers direct access to the instance variable.
Thanks again for your response. I'm sticking with the parameters for now.
>
-Beth
>
--
Tom Shelton
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is created
during the declaration instead of outside the class, enforcing the single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to the
base class instance in memory, so you could call the base class's functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class has its
own instance of myBase separate from any other instance, which makes sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before, but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
Actually, there is a mistake in that implementation... clsData should have a
private constructor. In other words, it should prevent any other classes from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class. I am not saying this is the
correct architecture. The more I've read, it sounds like you are trying to
develop a n-teir type application. You might want to do some reading on that
topic.
--
Tom Shelton
Thanks again, Tom.
I like that better.
I've read about n-tier development, but that's not really what I'm doing.
Everything is in one assembly for one project with one database. It's not a
large-scale thing, just departmental. It's not dependent on any modules
running on other servers, in other words.
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is created
during the declaration instead of outside the class, enforcing the single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to the
base class instance in memory, so you could call the base class's functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class has its
own instance of myBase separate from any other instance, which makes sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before, but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
Actually, there is a mistake in that implementation... clsData should have a
private constructor. In other words, it should prevent any other classes from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class. I am not saying this is the
correct architecture. The more I've read, it sounds like you are trying to
develop a n-teir type application. You might want to do some reading on that
topic.
--
Tom Shelton
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
but you can't listen for events from a singleton...
Sure you can.
I'm still not convined that this is the right path. I think really, more
information is needed on what your trying to achieve.
If I understand, now that I've read more - it sounds like your trying to
create a data abstraction layer. There are many ways to accomplish this, so
you might want to do a little more reading on n-tier achitectures. There are
in fact whole applications that will generate this kind of stuff for you :)
But, for simple stuff, I tend to do stuff like this
Friend MustInherit Class DataAccess
Private _connectionString As String
Public Sub New(ByVal connectionString As String)
_connectionString = connectionString
End Sub
' generic data access stuff
Public Function GetList(Of T) (ByVal procedure) As List(Of T)
Dim l As New List(Of T)
' I use attributes and reflection to generate the objects here
' from the resulting recordset. basically, i map the properties
' of type T to specific fields in the record set.
Return l
End Function
End Class
Friend Class UserDataAccess
Inherits DataAccess
Public Sub New (ByVal connectionString As String)
MyBase.New(connectionString)
End Sub
Public Function GetUsers() As List(Of User)
Return GetList(Of User)("getallusers")
End Function
Public Class
Public Class UserBuisnessLogic
Private _dataAccess As UserDataAccess
Public Sub New (string connectionString)
_dataAccess = new UserDataAccess
End Sub
Public Function GetUsers() As List(Of User)
return _dataAccess.GetUsers()
End Function
End Class
This of course Really, Really, basic. I have a framework that I've been
evolving overtime :) And to be real honest, it's all in C# - but many of the
concepts apply to VB. But, you might want to take a look at some resources on
this topic.
--
Tom Shelton
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks again, Tom.
I like that better.
I've read about n-tier development, but that's not really what I'm doing.
Everything is in one assembly for one project with one database. It's not a
large-scale thing, just departmental. It's not dependent on any modules
running on other servers, in other words.
N-Tier is more about a separation of layers then it is about multiple servers,
etc. N-tier is about layering of you application into multiple independent
layers. I often have one dll that contains all three layers - the point is
that I can easily separate them out, split them up or replace layers with
different pieces should the need arise.
--
Tom Shelton
Thanks, sloan.
I think.
Yes, I've been developing over 10 years now. I started with VB3, believe it
or not.
And yes, I have taken a couple of .NET courses. Didn't get through to me, I
guess.
Actually, I used to think I could support anybody else's VB code, until I
saw some written by a guy experienced in COBOL. Then I saw some code written
by engineers. Then I saw some code written by a FoxPro developer.
I usually rewrite the old stuff instead of trying to figure out what they
were doing.
So I gather...
You don't like my naming convention. Personally, I like being able to tell
the data type from the variable name.
You were thinking I was working on components that didn't access the
database directly? That I was implementing some middle-tier components? I'm
doing the whole thing, soup to nuts (actually, I've done the whole thing and
I'm revisiting it.)
I could have introduced additional layers of abstraction, but for this
project, it didn't make sense. It would be introducing abstraction for
abstraction's sake, not reuse.
You want to see connection strings in a config file instead of code. I'm
not a huge fan of config files, but I have seen them promoted. It's an
internal application using integrated security, so all I'm concerned about is
keeping people from accessing the wrong back end. I need to keep people in
prod from connecting to test, even though prod started out in the test
environment and they're structurally the same. I'm even exposing the
connection in Help/About so we're all clear on where we're connecting at
runtime.
You want to see the use of lists instead of collections. I think I can
accommodate you, there.
It's certainly not my intention to write code which pains you young
whipper-snappers, so if there's more I was supposed to pick up on, feel free
to share.
I need to take my nap now.
-Beth
"sloan" wrote:
>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that code
is doing. I might have in 1999.
................
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
You can write layers into one assembly....layers are a logical seperation.
I think its easier to put layers in different assembies (to avoid crossing
incorrect boundaries)......but you can do layers in one assembly.
I think of Tiers as different boundaries.
But you should be doing Layered development.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:24**********************************@microsof t.com...
Thanks again, Tom.
I like that better.
I've read about n-tier development, but that's not really what I'm doing.
Everything is in one assembly for one project with one database. It's not
a
large-scale thing, just departmental. It's not dependent on any modules
running on other servers, in other words.
"Tom Shelton" wrote:
>On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is
created
during the declaration instead of outside the class, enforcing the
single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to
the
base class instance in memory, so you could call the base class's
functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class
has its
own instance of myBase separate from any other instance, which makes
sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would
the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before,
but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
Actually, there is a mistake in that implementation... clsData should
have a
private constructor. In other words, it should prevent any other classes
from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class. I am not saying this is
the
correct architecture. The more I've read, it sounds like you are trying
to
develop a n-teir type application. You might want to do some reading on
that
topic.
--
Tom Shelton
//which pains you young
whipper-snappers,//
Huh?
I've been developing code for 10 years also (as in being paid ... for a
living).
I started with VB4, 16Bit for Win3.1.
So I don't think age has anything to do with it.
If you count the space invader knock-off game I wrote in the 6th grade on a
TRS80 using ascii characters, then I've been writing code for 24 years on
and off.
Wait, I took a Apple 2e course during my 5th grade summer. Make that 25
years.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:51**********************************@microsof t.com...
Thanks, sloan.
I think.
Yes, I've been developing over 10 years now. I started with VB3, believe
it
or not.
And yes, I have taken a couple of .NET courses. Didn't get through to me,
I
guess.
Actually, I used to think I could support anybody else's VB code, until I
saw some written by a guy experienced in COBOL. Then I saw some code
written
by engineers. Then I saw some code written by a FoxPro developer.
I usually rewrite the old stuff instead of trying to figure out what they
were doing.
So I gather...
You don't like my naming convention. Personally, I like being able to
tell
the data type from the variable name.
You were thinking I was working on components that didn't access the
database directly? That I was implementing some middle-tier components?
I'm
doing the whole thing, soup to nuts (actually, I've done the whole thing
and
I'm revisiting it.)
I could have introduced additional layers of abstraction, but for this
project, it didn't make sense. It would be introducing abstraction for
abstraction's sake, not reuse.
You want to see connection strings in a config file instead of code. I'm
not a huge fan of config files, but I have seen them promoted. It's an
internal application using integrated security, so all I'm concerned about
is
keeping people from accessing the wrong back end. I need to keep people
in
prod from connecting to test, even though prod started out in the test
environment and they're structurally the same. I'm even exposing the
connection in Help/About so we're all clear on where we're connecting at
runtime.
You want to see the use of lists instead of collections. I think I can
accommodate you, there.
It's certainly not my intention to write code which pains you young
whipper-snappers, so if there's more I was supposed to pick up on, feel
free
to share.
I need to take my nap now.
-Beth
"sloan" wrote:
>>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and
no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that
creates
them.
The code that creates them can use database related calls, OR (better)
the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that
code
is doing. I might have in 1999.
................
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microso ft.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor,
like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB &
";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to
the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the
code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing
the
object instance as a parameter?
Thanks for any help,
-Beth
Beth,
It sounds for me a bad idea to use VB6 style code where OOP can be used.
But as you want that, simple use modules instead of classes.
jmo
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
Sloan,
Sorry, I did not completely read your reply before I wrote mine.
I could have written, I agree with you Sloan.
Cor
"sloan" <sl***@ipass.netwrote in message
news:e1**************@TK2MSFTNGP05.phx.gbl...
>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and
no one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that
creates them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that code
is doing. I might have in 1999.
...............
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
>Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to
the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing
the
object instance as a parameter?
Thanks for any help,
-Beth
Tom,
I am glad you do.
I was a little bit disapointed that you were helping with this, and because
it is in a newsgroup than certainly sombody will use this in future.
Something like the by my so hated phrase "It is best
practise.................. whatever"
Cor
:-
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:eZ**************@TK2MSFTNGP04.phx.gbl...
On 2008-10-29, sloan <sl***@ipass.netwrote:
>>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and
no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that
creates
them.
The code that creates them can use database related calls, OR (better)
the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that
code
is doing. I might have in 1999.
...............
Yep... I have to agree.
--
Tom Shelton
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as this
would create a bigger footprint in the resulting code output ,
about your coding style ,,,, it would be a good idea for you to read this
book http://astore.amazon.com/vbdotnetcod...134366-2373937
Although i must say i have seen worse coding styles from people honestly
believing that they comply to MSF
i am just mentioning above link because of the comments in this thread wich
are partially valid after reading and conforming to the styles in above book
you can slap 90% of the coders around for not complying to the official MSF
, Practical guidelines and best practices rules .
But ,,,, honestly said it wil sure make you a bether and more productive
programmer if you comply to the basic rules of naming conventions just for
the simple fact that a lot of tools ( devpartner profiler to just call one )
comply to these rules so in my code i just simply declare a private field
and with just a short keyborard shortcut i can convert it to a correctly
named property
Regards
Michel Posseth [MCP]
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access classes, which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content, like
customerID, name, and phone. That's all business content I don't determine.
I don't hard code that stuff because it's outside of my control and too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables. The content of the tables the source code is
dependent on describe how the application should display, validate, manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes into a
separate .dll so I could reuse it for a web front-end. All the data access
requirements are the same from the presentation layer's point of view.
I don't see a lot of other developers taking this approach, and I see a lot
of class examples modeling business content, so I don't really expect many
people to understand what I'm trying to do, which is one reason why it's
harder for me to get help.
Thanks for trying, anyways.
"sloan" wrote:
You can write layers into one assembly....layers are a logical seperation.
I think its easier to put layers in different assembies (to avoid crossing
incorrect boundaries)......but you can do layers in one assembly.
I think of Tiers as different boundaries.
But you should be doing Layered development.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:24**********************************@microsof t.com...
Thanks again, Tom.
I like that better.
I've read about n-tier development, but that's not really what I'm doing.
Everything is in one assembly for one project with one database. It's not
a
large-scale thing, just departmental. It's not dependent on any modules
running on other servers, in other words.
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is
created
during the declaration instead of outside the class, enforcing the
single
shared instance, as long as no caller decides to instantiate the class.
I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on' to
the
base class instance in memory, so you could call the base class's
functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way. The derived class
has its
own instance of myBase separate from any other instance, which makes
sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would
the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword before,
but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
Actually, there is a mistake in that implementation... clsData should
have a
private constructor. In other words, it should prevent any other classes
from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class. I am not saying this is
the
correct architecture. The more I've read, it sounds like you are trying
to
develop a n-teir type application. You might want to do some reading on
that
topic.
--
Tom Shelton
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable code. It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now. Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microsof t.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content, like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables. The content of the tables the source code is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of view.
I don't see a lot of other developers taking this approach, and I see a
lot
of class examples modeling business content, so I don't really expect many
people to understand what I'm trying to do, which is one reason why it's
harder for me to get help.
Thanks for trying, anyways.
"sloan" wrote:
>You can write layers into one assembly....layers are a logical
seperation.
I think its easier to put layers in different assembies (to avoid
crossing
incorrect boundaries)......but you can do layers in one assembly.
I think of Tiers as different boundaries.
But you should be doing Layered development.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:24**********************************@microso ft.com...
Thanks again, Tom.
I like that better.
I've read about n-tier development, but that's not really what I'm
doing.
Everything is in one assembly for one project with one database. It's
not
a
large-scale thing, just departmental. It's not dependent on any
modules
running on other servers, in other words.
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Thanks, Tom.
It looks recursive, but I see where the new instance of the class is
created
during the declaration instead of outside the class, enforcing the
single
shared instance, as long as no caller decides to instantiate the
class.
I got the instance reference to work without passing an instance of
the
class as a parameter to other class's constructors, and that was
what I
wanted.
I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.
I was thinking when you instantiate a derived class, it 'latched on'
to
the
base class instance in memory, so you could call the base class's
functions
at runtime and get the same results as if you'd called the base
class's
functions directly, but it doesn't work that way. The derived class
has its
own instance of myBase separate from any other instance, which makes
sense,
because you're not guaranteed to have any instance of the base class
in
memory or you could have several instances, and then which one would
the
derived class 'latch on' to?
Thanks again for your response. I'd seen the 'shared' keyword
before,
but
not used on a new instance of itself.
I guess that's what they mean by 'singleton.'
-Beth
Actually, there is a mistake in that implementation... clsData should
have a
private constructor. In other words, it should prevent any other
classes
from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class. I am not saying this is
the
correct architecture. The more I've read, it sounds like you are
trying
to
develop a n-teir type application. You might want to do some reading
on
that
topic.
--
Tom Shelton
Hi again, sloan.
When I was in high school, we coded on Commodore Pets with a cassete tape
for storage. I had a computer at home my dad bought for $99. I think it was
a TRS-A.
Not sure, that was a long time ago.
Oddly enough, my first job was for the Apple//e platform in AppleSoft BASIC
for the public schools market. When the GS came out, we coded in 6502
assembly. It was a big deal because all of a sudden we had a lot more memory
and we didn't have to use the unsupported language card to do anything useful.
Of course, no one else was developing for that platform, so I switched to MS
and I've been there ever sense.
I guess I just haven't kept up as well as you have over the years, but I
haven't had a lot of support, either.
I figured maybe someone dumped on you for something similar 10 years ago and
you were paying it forward.
"sloan" wrote:
>
//which pains you young
whipper-snappers,//
Huh?
I've been developing code for 10 years also (as in being paid ... for a
living).
I started with VB4, 16Bit for Win3.1.
So I don't think age has anything to do with it.
If you count the space invader knock-off game I wrote in the 6th grade on a
TRS80 using ascii characters, then I've been writing code for 24 years on
and off.
Wait, I took a Apple 2e course during my 5th grade summer. Make that 25
years.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:51**********************************@microsof t.com...
Thanks, sloan.
I think.
Yes, I've been developing over 10 years now. I started with VB3, believe
it
or not.
And yes, I have taken a couple of .NET courses. Didn't get through to me,
I
guess.
Actually, I used to think I could support anybody else's VB code, until I
saw some written by a guy experienced in COBOL. Then I saw some code
written
by engineers. Then I saw some code written by a FoxPro developer.
I usually rewrite the old stuff instead of trying to figure out what they
were doing.
So I gather...
You don't like my naming convention. Personally, I like being able to
tell
the data type from the variable name.
You were thinking I was working on components that didn't access the
database directly? That I was implementing some middle-tier components?
I'm
doing the whole thing, soup to nuts (actually, I've done the whole thing
and
I'm revisiting it.)
I could have introduced additional layers of abstraction, but for this
project, it didn't make sense. It would be introducing abstraction for
abstraction's sake, not reuse.
You want to see connection strings in a config file instead of code. I'm
not a huge fan of config files, but I have seen them promoted. It's an
internal application using integrated security, so all I'm concerned about
is
keeping people from accessing the wrong back end. I need to keep people
in
prod from connecting to test, even though prod started out in the test
environment and they're structurally the same. I'm even exposing the
connection in Help/About so we're all clear on where we're connecting at
runtime.
You want to see the use of lists instead of collections. I think I can
accommodate you, there.
It's certainly not my intention to write code which pains you young
whipper-snappers, so if there's more I was supposed to pick up on, feel
free
to share.
I need to take my nap now.
-Beth
"sloan" wrote:
>
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and
no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that
creates
them.
The code that creates them can use database related calls, OR (better)
the
business objects and collections can be created totally independant of a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that
code
is doing. I might have in 1999.
................
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor,
like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB &
";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to
the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the
code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing
the
object instance as a parameter?
Thanks for any help,
-Beth
Hi, Cor.
Thanks for your response.
I'm using a VB6 naming convention, yes, but not modules because you can't
instantiate one or more instances of a module, can't listen for events, and
can't associate the actions on a data structure with the data structure
itself. Not to mention all the other OO stuff you can't do.
I can see why people are religious about using OO methods instead of
structured programming, but I haven't found a lot of instructor-led classes
focusing on those concepts outside of UML. I had the material presented in
college, of course, but I don't remember that. Yes, there's tons of books and
info online, but I learn better from asking someone questions after they've
presented something and I need to make sure I understand them.
If you're aware of a 'OO for VB6-to-.NET programmers' forum somewhere,
please let me know. Naming conventions I can change.
I'm not even sure if Microsoft has an OO forum somewhere, for those of us
trying to learn more.
Well, anyways, thanks for replying.
-Beth
"Cor Ligthert[MVP]" wrote:
Beth,
It sounds for me a bad idea to use VB6 style code where OOP can be used.
But as you want that, simple use modules instead of classes.
jmo
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
Thanks for your response, Michael.
I know you can create 'bad' code in any language reguardless of the amount
of reading you've done or training you've had, and dealing with other
people's code you don't like, agree with, or support is part of being a
developer.
I don't like C-style languages because they're too symbolic and can combine
too many operations in one line of code. It's for a different level of geek
than me.
What I've noticed about the newer naming convention is it doesn't include
the data type of the variable and the module-level scope prefix (m_) was
dropped in favor of just the _.
I can see, though, that if you're using automated tools to generate your
code, you need to follow the tool's expected naming convention. Obviously, I
haven't used any. I write everything from scratch.
I'm assuming the .NET naming convention is published on MS's web site
somewhere, like the VB6 convention was, so I should be able to find it.
Thanks again for your response. I usually work by myself or with people
with less experience than me so the rest of the world can just fly by me and
I'll never even notice.
-Beth
"Michel Posseth [MCP]" wrote:
>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as this
would create a bigger footprint in the resulting code output ,
about your coding style ,,,, it would be a good idea for you to read this
book
http://astore.amazon.com/vbdotnetcod...134366-2373937
Although i must say i have seen worse coding styles from people honestly
believing that they comply to MSF
i am just mentioning above link because of the comments in this thread wich
are partially valid after reading and conforming to the styles in above book
you can slap 90% of the coders around for not complying to the official MSF
, Practical guidelines and best practices rules .
But ,,,, honestly said it wil sure make you a bether and more productive
programmer if you comply to the basic rules of naming conventions just for
the simple fact that a lot of tools ( devpartner profiler to just call one )
comply to these rules so in my code i just simply declare a private field
and with just a short keyborard shortcut i can convert it to a correctly
named property
Regards
Michel Posseth [MCP]
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:8D**********************************@microsof t.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor, like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?
Thanks for any help,
-Beth
On Oct 29, 11:04*pm, "Cor Ligthert[MVP]" <Notmyfirstn...@planet.nl>
wrote:
Tom,
I am glad you do.
I was a little bit disapointed that you were helping with this, and because
it is in a newsgroup than certainly sombody will use this in future.
I try to help anyone. I knew that the code she was presenting was not
"best practice" material, but many people have jobs and have to work
on a deadline. I try to point out things that I don't feel are best
practice, but in a careful way. For many people, they just need to
get the job done.
--
Tom Shelton
Thanks again for replying, sloan.
I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)
which I don't think should be in code because it's outside the
responsibility of the IT department. The business should be able to change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.
When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple of
tables I created for the purpose of interpreting data in their content tables.
For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their app
to meet their business needs as they change over time. I have no interest in
maintaining their content.
A different approach, I know. Most examples I've seen code business content
instead of keeping it separate.
I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET
It's already in VB.NET. By 'translating' I'm assuming you mean something
other than changing the naming convention, which I wouldn't learn a whole lot
from.
Please forgive my ignorance, I'm a little slow.
Oh, and I do intend to use Lists of class types instead of collections to
strengthen the data types. I knew I could do that, just hadn't spent the
time to look up how. Figured I'd meet the business need with collections
first.
Thanks again for your response,
-Beth
"sloan" wrote:
>
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable code. It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now. Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microsof t.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content, like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables. The content of the tables the source code is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of view.
I don't see a lot of other developers taking this approach, and I see a
lot
of class examples modeling business content, so I don't really expect many
people to understand what I'm trying to do, which is one reason why it's
harder for me to get help.
Thanks for trying, anyways.
Beth,
Don't mix up OO and OOP, OOP is to be able to use small memory with tons of
classes.
At the moment I am busy with doing some corrections on a VB6 program that
was made by others 8 years ago. It is nicely done and still it is a hell to
do as you are used to .Net programming languages.
In OOP you create small methods which can be seen on them self and as you
use them more by making classes of them.
Try it, add the end you will think, how could I ever do it on the classic
way.
I was in past a devoted follower of Dijkstra, but that was in the time that
there were no PC's, mobiles, Internet and more of that stuff.
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:FD**********************************@microsof t.com...
Hi, Cor.
Thanks for your response.
I'm using a VB6 naming convention, yes, but not modules because you can't
instantiate one or more instances of a module, can't listen for events,
and
can't associate the actions on a data structure with the data structure
itself. Not to mention all the other OO stuff you can't do.
I can see why people are religious about using OO methods instead of
structured programming, but I haven't found a lot of instructor-led
classes
focusing on those concepts outside of UML. I had the material presented
in
college, of course, but I don't remember that. Yes, there's tons of books
and
info online, but I learn better from asking someone questions after
they've
presented something and I need to make sure I understand them.
If you're aware of a 'OO for VB6-to-.NET programmers' forum somewhere,
please let me know. Naming conventions I can change.
I'm not even sure if Microsoft has an OO forum somewhere, for those of us
trying to learn more.
Well, anyways, thanks for replying.
-Beth
"Cor Ligthert[MVP]" wrote:
>Beth,
It sounds for me a bad idea to use VB6 style code where OOP can be used.
But as you want that, simple use modules instead of classes.
jmo
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microso ft.com...
Hello.
I'm trying to find another way to share an instance of an object with
other
classes.
I started by passing the instance to the other class's constructor,
like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB &
";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly to
the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the
code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with passing
the
object instance as a parameter?
Thanks for any help,
-Beth
Thanks for your response, Cor.
You're right, OO is one big thing to me. I don't know enough about it to
break it out into additional descriptive letters.
re: It is nicely done and still it is a hell to do as you are used to .Net
programming languages.
You mean converting an application following structured programming methods
to one following OO(x) methods is a pain because you have to do all of the
object analysis?
I thought people rewrote those things from scratch instead of trying to do a
conversion.
I'd like to understand when you say:
In OOP you create small methods which can be seen on them self and as you
use them more by making classes of them.
but I don't. Can you say that in a different way?
Are you talking about methods written independently of classes which provide
functions independent of the type of their caller?
Thanks again,
-Beth
"Cor Ligthert[MVP]" wrote:
Beth,
Don't mix up OO and OOP, OOP is to be able to use small memory with tons of
classes.
At the moment I am busy with doing some corrections on a VB6 program that
was made by others 8 years ago. It is nicely done and still it is a hell to
do as you are used to .Net programming languages.
In OOP you create small methods which can be seen on them self and as you
use them more by making classes of them.
Try it, add the end you will think, how could I ever do it on the classic
way.
I was in past a devoted follower of Dijkstra, but that was in the time that
there were no PC's, mobiles, Internet and more of that stuff.
Cor
Tom,
I tried to change it so that the new instance of clsData was created in the
private constructor instead of the declaration, but that didn't work.
Guess declarations are evaluated before the constructor executes…
Thanks again for the help,
-Beth
"Tom Shelton" wrote:
On 2008-10-29, Beth <Be**@discussions.microsoft.comwrote:
Actually, there is a mistake in that implementation... clsData should have a
private constructor. In other words, it should prevent any other classes from
instantiating it :)
Here is the correction...
Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub
' your public instance methods here
Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class
Now, there is only on instance of this class.
//I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET//
Take the code sample at the blog entry I provided..and translating it to
VB.NET.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
The downloadable c# code. There is a "download here" link there.
You can do the "2.0" version ... however, timewise the 1.1 version will be
faster to translate.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:A6**********************************@microsof t.com...
Thanks again for replying, sloan.
I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)
which I don't think should be in code because it's outside the
responsibility of the IT department. The business should be able to
change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.
When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple of
tables I created for the purpose of interpreting data in their content
tables.
For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their
app
to meet their business needs as they change over time. I have no interest
in
maintaining their content.
A different approach, I know. Most examples I've seen code business
content
instead of keeping it separate.
I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET
It's already in VB.NET. By 'translating' I'm assuming you mean something
other than changing the naming convention, which I wouldn't learn a whole
lot
from.
Please forgive my ignorance, I'm a little slow.
Oh, and I do intend to use Lists of class types instead of collections to
strengthen the data types. I knew I could do that, just hadn't spent the
time to look up how. Figured I'd meet the business need with collections
first.
Thanks again for your response,
-Beth
"sloan" wrote:
>>
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would
read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable code.
It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now.
Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microso ft.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content,
like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables. The content of the tables the source code is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes
into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of view.
I don't see a lot of other developers taking this approach, and I see a
lot
of class examples modeling business content, so I don't really expect
many
people to understand what I'm trying to do, which is one reason why
it's
harder for me to get help.
Thanks for trying, anyways.
Hi, again, sloan.
Thanks for sharing your sample code.
I see a lot of references in the code to business concepts like customers
and orders.
I avoid modeling business objects in source code, because the objects change
at whim. They're owned by the business, after all, not by me. If the
business needs to change something about the attributes or behavior of their
objects, ideally, I'd like them to do it with an administrative application
allowing them to configure the deployed application in a way that meets their
business needs. If they're not up to that, I can make their changes on the
back end myself. The source code doesn't have to change.
It's not that I don't get what you're saying, but the cost of implemeting
business objects in code is too high, in my opinion.
But a lot of other people seem to be doing it, so I guess I can't expect
most people to understand what I'm doing.
Thanks for taking a shot at it, anyways.
-Beth
"sloan" wrote:
//I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET//
Take the code sample at the blog entry I provided..and translating it to
VB.NET.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
The downloadable c# code. There is a "download here" link there.
You can do the "2.0" version ... however, timewise the 1.1 version will be
faster to translate.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:A6**********************************@microsof t.com...
Thanks again for replying, sloan.
I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)
which I don't think should be in code because it's outside the
responsibility of the IT department. The business should be able to
change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.
When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple of
tables I created for the purpose of interpreting data in their content
tables.
For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their
app
to meet their business needs as they change over time. I have no interest
in
maintaining their content.
A different approach, I know. Most examples I've seen code business
content
instead of keeping it separate.
I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET
It's already in VB.NET. By 'translating' I'm assuming you mean something
other than changing the naming convention, which I wouldn't learn a whole
lot
from.
Please forgive my ignorance, I'm a little slow.
Oh, and I do intend to use Lists of class types instead of collections to
strengthen the data types. I knew I could do that, just hadn't spent the
time to look up how. Figured I'd meet the business need with collections
first.
Thanks again for your response,
-Beth
"sloan" wrote:
>
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would
read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable code.
It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now.
Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microsof t.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content,
like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables. The content of the tables the source code is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes
into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of view.
I don't see a lot of other developers taking this approach, and I see a
lot
of class examples modeling business content, so I don't really expect
many
people to understand what I'm trying to do, which is one reason why
it's
harder for me to get help.
Thanks for trying, anyways.
The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvider.
Somehow ( and I don't know how) they're able to tack on properties
dynamically to a User.
For instance, you could decide that you needed to track
height/weight/favorite color at your website.
They are able to pull off some dynamic property voodoo stuff .........
You are correct, I don't deal with this situation. http://msdn.microsoft.com/en-us/library/d8b58y5d.aspx
I have zero idea whether that'll help you or not.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:68**********************************@microsof t.com...
Hi, again, sloan.
Thanks for sharing your sample code.
I see a lot of references in the code to business concepts like customers
and orders.
I avoid modeling business objects in source code, because the objects
change
at whim. They're owned by the business, after all, not by me. If the
business needs to change something about the attributes or behavior of
their
objects, ideally, I'd like them to do it with an administrative
application
allowing them to configure the deployed application in a way that meets
their
business needs. If they're not up to that, I can make their changes on
the
back end myself. The source code doesn't have to change.
It's not that I don't get what you're saying, but the cost of implemeting
business objects in code is too high, in my opinion.
But a lot of other people seem to be doing it, so I guess I can't expect
most people to understand what I'm doing.
Thanks for taking a shot at it, anyways.
-Beth
"sloan" wrote:
>//I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the
code
to VB.NET//
Take the code sample at the blog entry I provided..and translating it to
VB.NET.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
The downloadable c# code. There is a "download here" link there.
You can do the "2.0" version ... however, timewise the 1.1 version will
be
faster to translate.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:A6**********************************@microso ft.com...
Thanks again for replying, sloan.
I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)
which I don't think should be in code because it's outside the
responsibility of the IT department. The business should be able to
change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.
When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple
of
tables I created for the purpose of interpreting data in their content
tables.
For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their
app
to meet their business needs as they change over time. I have no
interest
in
maintaining their content.
A different approach, I know. Most examples I've seen code business
content
instead of keeping it separate.
I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the
code
to VB.NET
It's already in VB.NET. By 'translating' I'm assuming you mean
something
other than changing the naming convention, which I wouldn't learn a
whole
lot
from.
Please forgive my ignorance, I'm a little slow.
Oh, and I do intend to use Lists of class types instead of collections
to
strengthen the data types. I knew I could do that, just hadn't spent
the
time to look up how. Figured I'd meet the business need with
collections
first.
Thanks again for your response,
-Beth
"sloan" wrote:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would
read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable
code.
It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative
for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now.
Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if
you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microso ft.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access
classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content,
like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and
too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside
the
business content tables. The content of the tables the source code
is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes
into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of
view.
I don't see a lot of other developers taking this approach, and I
see a
lot
of class examples modeling business content, so I don't really
expect
many
people to understand what I'm trying to do, which is one reason why
it's
harder for me to get help.
Thanks for trying, anyways.
Beth,
I can of course not give here a kind of course, however assume that this is
Public Class Sample
Private Sub Start()
Dim theSalaryMethod As New Salary
Dim PersonsSalary
PersonsSalary = theSalaryMethod.WeekSalary(1, 40)
End Sub
End Class
///
What you see above is instancing (creating) an object in your program which
has as template the class salary.
Somewhere else you have a class salary, by instance in your business layer
or as complete seperated project.
That Salary class uses again an object that is instanced (not showed) in by
instance a datalayer to get Employee information that contains his/here hour
rate.
\\\
End Class
Public Class Salary
Private ReadOnly Property HourRate() As Decimal
Get
Return 100 'Normal this will be something from another
'class which returns by instance employee.information
End Get
End Property
Public Function WeekSalary(ByVal EmployeeNumber As Integer, ByVal
TotalWeekHours As Integer) As Decimal
Return HourRate * TotalWeekHours
End Function
End Class
///
There are many advantages, you can create one method that you can use
everywhere to calculate however more important is that you can create small
parts that are easily to maintain by someone else as you do it well you see
direct what is done.
And beside that, the objects are automaticly cleaned up as they are not
needed anymore. You mostly don't have to do anything for that because that
is why .Net is called managed code.
I spare you the facts about dispose other wise some people think they have
to correct that. Simply look than at the samples at MSDN. You seldom see in
those the dispose used.
Cor
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:4C**********************************@microsof t.com...
Hi again, sloan.
When I was in high school, we coded on Commodore Pets with a cassete tape
for storage. I had a computer at home my dad bought for $99. I think it
was
a TRS-A.
Not sure, that was a long time ago.
Oddly enough, my first job was for the Apple//e platform in AppleSoft
BASIC
for the public schools market. When the GS came out, we coded in 6502
assembly. It was a big deal because all of a sudden we had a lot more
memory
and we didn't have to use the unsupported language card to do anything
useful.
Of course, no one else was developing for that platform, so I switched to
MS
and I've been there ever sense.
I guess I just haven't kept up as well as you have over the years, but I
haven't had a lot of support, either.
I figured maybe someone dumped on you for something similar 10 years ago
and
you were paying it forward.
"sloan" wrote:
>>
//which pains you young
whipper-snappers,//
Huh?
I've been developing code for 10 years also (as in being paid ... for a
living).
I started with VB4, 16Bit for Win3.1.
So I don't think age has anything to do with it.
If you count the space invader knock-off game I wrote in the 6th grade on
a
TRS80 using ascii characters, then I've been writing code for 24 years on
and off.
Wait, I took a Apple 2e course during my 5th grade summer. Make that 25
years.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:51**********************************@microso ft.com...
Thanks, sloan.
I think.
Yes, I've been developing over 10 years now. I started with VB3,
believe
it
or not.
And yes, I have taken a couple of .NET courses. Didn't get through to
me,
I
guess.
Actually, I used to think I could support anybody else's VB code, until
I
saw some written by a guy experienced in COBOL. Then I saw some code
written
by engineers. Then I saw some code written by a FoxPro developer.
I usually rewrite the old stuff instead of trying to figure out what
they
were doing.
So I gather...
You don't like my naming convention. Personally, I like being able to
tell
the data type from the variable name.
You were thinking I was working on components that didn't access the
database directly? That I was implementing some middle-tier
components?
I'm
doing the whole thing, soup to nuts (actually, I've done the whole
thing
and
I'm revisiting it.)
I could have introduced additional layers of abstraction, but for this
project, it didn't make sense. It would be introducing abstraction for
abstraction's sake, not reuse.
You want to see connection strings in a config file instead of code.
I'm
not a huge fan of config files, but I have seen them promoted. It's an
internal application using integrated security, so all I'm concerned
about
is
keeping people from accessing the wrong back end. I need to keep
people
in
prod from connecting to test, even though prod started out in the test
environment and they're structurally the same. I'm even exposing the
connection in Help/About so we're all clear on where we're connecting
at
runtime.
You want to see the use of lists instead of collections. I think I can
accommodate you, there.
It's certainly not my intention to write code which pains you young
whipper-snappers, so if there's more I was supposed to pick up on, feel
free
to share.
I need to take my nap now.
-Beth
"sloan" wrote:
I think that whole bit of code is ... .. hurting.....
You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code,
and
no
one at your workplace has taken a VB.NET course yet.
Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
This is a layered application.
The business objects and collections are seperate from the code that
creates
them.
The code that creates them can use database related calls, OR (better)
the
business objects and collections can be created totally independant of
a
database.
(One reason? UnitTesting)
Your connection strings should be kept in a config file. You've got
hardcoding all over the place.
I'm not trying to be mean...but youch....... I have no idea what that
code
is doing. I might have in 1999.
................
"Beth" <Be**@discussions.microsoft.comwrote in message
news:8D**********************************@microso ft.com...
Hello.
I'm trying to find another way to share an instance of an object
with
other
classes.
I started by passing the instance to the other class's constructor,
like
this:
Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB &
";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
This works, but I don't like it. I want clsUsers to refer directly
to
the
instance variable in clsData instead of passing a parameter.
Then I saw an example using inheritance that I liked, so I added:
Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function
To clsData and I deleted the constructor in clsUsers and changed the
code
to:
Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable
Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")
but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.
Is there another way I can do this, or do I need to stick with
passing
the
object instance as a parameter?
Thanks for any help,
-Beth
Hi again, sloan.
To me, that link looks like it's describing a place to store user preferences.
It wouldn't be appropriate to store business objects, in other words.
If you're curious, I can give you more information about how I do it.
It basically involves 2 tables, a bunch of views, stored procedures, and
functions, and code which builds SQL syntax dynamically.
Not for everyone, I'm sure, but I like it.
Keeps the back end separate from the code.
Thanks again for your help and interest,
-Beth
"sloan" wrote:
The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvider.
Somehow ( and I don't know how) they're able to tack on properties
dynamically to a User.
For instance, you could decide that you needed to track
height/weight/favorite color at your website.
They are able to pull off some dynamic property voodoo stuff .........
You are correct, I don't deal with this situation.
http://msdn.microsoft.com/en-us/library/d8b58y5d.aspx
I have zero idea whether that'll help you or not.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:68**********************************@microsof t.com...
Hi, again, sloan.
Thanks for sharing your sample code.
I see a lot of references in the code to business concepts like customers
and orders.
I avoid modeling business objects in source code, because the objects
change
at whim. They're owned by the business, after all, not by me. If the
business needs to change something about the attributes or behavior of
their
objects, ideally, I'd like them to do it with an administrative
application
allowing them to configure the deployed application in a way that meets
their
business needs. If they're not up to that, I can make their changes on
the
back end myself. The source code doesn't have to change.
It's not that I don't get what you're saying, but the cost of implemeting
business objects in code is too high, in my opinion.
But a lot of other people seem to be doing it, so I guess I can't expect
most people to understand what I'm doing.
Thanks for taking a shot at it, anyways.
-Beth
"sloan" wrote:
//I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the
code
to VB.NET//
Take the code sample at the blog entry I provided..and translating it to
VB.NET.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
The downloadable c# code. There is a "download here" link there.
You can do the "2.0" version ... however, timewise the 1.1 version will
be
faster to translate.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:A6**********************************@microsof t.com...
Thanks again for replying, sloan.
I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)
which I don't think should be in code because it's outside the
responsibility of the IT department. The business should be able to
change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.
When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple
of
tables I created for the purpose of interpreting data in their content
tables.
For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their
app
to meet their business needs as they change over time. I have no
interest
in
maintaining their content.
A different approach, I know. Most examples I've seen code business
content
instead of keeping it separate.
I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the
code
to VB.NET
It's already in VB.NET. By 'translating' I'm assuming you mean
something
other than changing the naming convention, which I wouldn't learn a
whole
lot
from.
Please forgive my ignorance, I'm a little slow.
Oh, and I do intend to use Lists of class types instead of collections
to
strengthen the data types. I knew I could do that, just hadn't spent
the
time to look up how. Figured I'd meet the business need with
collections
first.
Thanks again for your response,
-Beth
"sloan" wrote:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
There is the 1.1 version of my other blog entry I gave you.
I would start there. Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version. So I would
read
(slowly) my 1.1 notes.
My 1.1 article has some links at the bottom.
Both the 1.1 and 2.0 versions of my blog entries have downloadable
code.
It
uses the Northwind database.
Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know? I'm a whipper snapper.
HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative
for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow. Reread a month from now.
Reread
it 3 months from now. Reread it 6 months from now.
Reread it every 3 months for the next 2 years.
.........
At the very least I would create strong(typed) DataSet objects....if
you
don't want a full custom class/collection solution.
Good luck.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:53**********************************@microsof t.com...
re: you should be doing Layered development
OK, I thought I was, but maybe not.
I have the presentation layer separated from the data access
classes,
which
are independent of the business content tables on the database.
I don't have any source code (classes) containing business content,
like
customerID, name, and phone. That's all business content I don't
determine.
I don't hard code that stuff because it's outside of my control and
too
volatile.
My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside
the
business content tables. The content of the tables the source code
is
dependent on describe how the application should display, validate,
manage,
and/or exercise data in the business content tables.
I was thinking I 'should' be able to compile my data access classes
into a
separate .dll so I could reuse it for a web front-end. All the data
access
requirements are the same from the presentation layer's point of
view.
I don't see a lot of other developers taking this approach, and I
see a
lot
of class examples modeling business content, so I don't really
expect
many
people to understand what I'm trying to do, which is one reason why
it's
harder for me to get help.
Thanks for trying, anyways.
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a second
copy.
If there's no new copy created of an object variable parameter, I don't see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as this
would create a bigger footprint in the resulting code output ,
sloan wrote:
The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvider.
Somehow ( and I don't know how) they're able to tack on properties
dynamically to a User.
Wandering OT, but see the section "Specifying a Profile Provider" in http://aspnet.4guysfromrolla.com/articles/101106-1.aspx
Andrew
Hi, again, Cor.
Thanks for the demonstration of coding with classes, creating instances, and
calling methods.
I thought I was doing that, but I must be doing something wrong.
I'm sure my error jumped right out at you- could you review my code below
and tell me which piece I should rewrite? You don't have to tell me how,
just where. I don't really understand sloan's comments, either, and please
forgive the code's naming convention.
Thanks again for your help,
-Beth
--------
"Cor Ligthert[MVP]" wrote:
Beth,
I can of course not give here a kind of course, however assume that this is
Public Class Sample
Private Sub Start()
Dim theSalaryMethod As New Salary
Dim PersonsSalary
PersonsSalary = theSalaryMethod.WeekSalary(1, 40)
End Sub
End Class
--------
"sloan" wrote:
You're tied your clsUsers to always coming from the database.
The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database. (One reason? UnitTesting)
---------
"Beth" <Be**@discussions.microsoft.com wrote in message
news:8D**********************************@microsof t.com...
>
Friend Class clsData ' job is to provide access to the database for the project
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String
Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String
If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated Security=true"
m_sConnect = m_sConnect & ";Application Name = " & My.Application.Info.AssemblyName
m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)
m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class
Friend Class clsUsers ' job is to provide access to the users table in the database
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable
Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub
Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")
Hello Beth ,
A reference type is always manipulated using pointers , if you pas a
reference by value what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .
What happens if you pass a reference type By Ref ? , Well it does exactly
what it says it makes a new reference variabel that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
..
Although you would probably never notice annything , typically you should
always pass reference variables by value just be aware that they can get
modified
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)
HTH
Michel Posseth [MCP] http://www.vbdotnetcoder.com
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
Hello Beth ,
A reference type is always manipulated using pointers , if you pas a
reference by value what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .
What happens if you pass a reference type By Ref ? , Well it does exactly
what it says it makes a new reference variabel that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
..
Although you would probably never notice annything , typically you should
always pass reference variables by value just be aware that they can get
modified
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)
HTH
Michel Posseth [MCP] http://www.vbdotnetcoder.com
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
Hello Beth ,
A reference type is always manipulated using pointers , if you pas a
reference by value what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .
What happens if you pass a reference type By Ref ? , Well it does exactly
what it says it makes a new reference variabel that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
..
Although you would probably never notice annything , typically you should
always pass reference variables by value just be aware that they can get
modified
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)
HTH
Michel Posseth [MCP] http://www.vbdotnetcoder.com
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
Hello Beth ,
A reference type is always manipulated using pointers , if you pas a
reference by value what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .
What happens if you pass a reference type By Ref ? , Well it does exactly
what it says it makes a new reference variabel that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
..
Although you would probably never notice annything , typically you should
always pass reference variables by value just be aware that they can get
modified
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)
HTH
Michel Posseth [MCP] http://www.vbdotnetcoder.com
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
Beth,
Adding something to the correct reply from Michel (with the exception what I
understand of his boxing, but he tells that this is his own method, so not
discussa ble) :-)
The ByRef is for when the referenced object is immutable. Like a string or
an original array
Have a look at this sample code
dim a = "Michel"
myMethod(a)
Private Sub myMethod(byXXX a as string)
'Asume this method contains only
a = "Beth"
This creates a new object with a new reference.
'As the referenence is byVal to object "Michel", then that will not change
the reference to Michel, the reference stays the same
'As you do this ByRef, then the reference which was pointing to "Michel"
will be changed to new reference to "Beth"
And the object to Michel will automaticly be removed as the Garbage
Collector starts working by instance as your video controler does some
screen refreshing while the available memory is low.
Cor.
"Beth" <Be**@discussions.microsoft.comwrote in message
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
Thanks, Michel.
I think I get it now.
When passing a variable created by instantiating a class, there's never
another copy made, so passing it ByRef just introduces an additional layer of
indirection.
Passing the same instance of a variable to multiple routines just creates
multiple pointers to the same variable in memory, so everyone sees everyone
else's changes.
When you say:
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding
are you saying you only pass objects as parameters?
If so, that's interesting, but we don't have to go into the details of why
today.
Thanks again,
-Beth
"Michel Posseth" wrote:
Hello Beth ,
A reference type is always manipulated using pointers , if you pas a
reference by value what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .
What happens if you pass a reference type By Ref ? , Well it does exactly
what it says it makes a new reference variabel that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
..
Although you would probably never notice annything , typically you should
always pass reference variables by value just be aware that they can get
modified
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)
HTH
Michel Posseth [MCP]
http://www.vbdotnetcoder.com
"Beth" <Be**@discussions.microsoft.comschreef in bericht
news:27**********************************@microsof t.com...
Hi, again, Michel.
I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects. What do you see as the
advantage
of using ByVal over ByRef for object parameters?
I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a
second
copy.
If there's no new copy created of an object variable parameter, I don't
see
how it can matter which one you use.
Or is it more of a convention thing? Pass ByVal whenever you can?
Thanks for helping me understand,
-Beth
"Michel Posseth [MCP]" wrote:
>
Hello Beth,
There is nothing wrong with passing an initialized class as a parameter
to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer , so no new
instances are created , you still hold one instance of your class .
You can easiliy proove and confirm this yourself changes in the passed
class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance as
this
would create a bigger footprint in the resulting code output ,
OK, Cor, pardon my considerable ignorance, but I thought the whole question
was what is the value of 'a' AFTER myMethod is called.
If you have:
dim a = "Michel"
myMethod(a)
msgbox("a is " & a)
and myMethod is:
Private Sub myMethod(byVal a as string)
a = "Beth"
then the message says 'a is Michel'. If 'a' is passed byRef, the message
says 'a is Beth'. When 'a' is passed byVal, then a second copy of 'a' is
created in memory, instead of a pointer to the existing variable declared by
the caller when it's passed byRef.
Both variables would be marked (or whatever) for garbage collection when
they fell out of scope, although the ByRef variable can't be marked as trash
when it falls out of scope in myMethod because the caller still has a
reference to it, so it will fall out of scope within the calling routine.
The 'a' passed byVal will fall out of scope within myMethod, along with all
the other variables declared in myMethod.
So you use byVal when you want the variable to remain immutable (unchanged,
or not mutating,) and byRef when you want the variable used as an output
parameter.
But I think you know that, so when you say:
ByRef is for when the referenced object is immutable
you're referring to the pointer being immutable, not the value. Although I
thought pointers were always immutable, and it was just a question of whether
or not another one gets created.
That's my understanding, anyways, but if I'm off somewhere, feel free to let
me know.
Thanks again for your response,
-Beth
"Cor Ligthert[MVP]" wrote:
Beth,
Adding something to the correct reply from Michel (with the exception what I
understand of his boxing, but he tells that this is his own method, so not
discussa ble) :-)
The ByRef is for when the referenced object is immutable. Like a string or
an original array
Have a look at this sample code
dim a = "Michel"
myMethod(a)
Private Sub myMethod(byXXX a as string)
'Asume this method contains only
a = "Beth"
This creates a new object with a new reference.
'As the referenence is byVal to object "Michel", then that will not change
the reference to Michel, the reference stays the same
'As you do this ByRef, then the reference which was pointing to "Michel"
will be changed to new reference to "Beth"
And the object to Michel will automaticly be removed as the Garbage
Collector starts working by instance as your video controler does some
screen refreshing while the available memory is low.
Cor.
The object is immutable, everytime a simple change is made in a string, a
new string is created with in fact a new reference.
That is the reason that changing a string can cost more in time and memory
than a string builder.
You are mixing up the ByVal and the ByRef from the time there were no
objects.
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:EA**********************************@microsof t.com...
OK, Cor, pardon my considerable ignorance, but I thought the whole
question
was what is the value of 'a' AFTER myMethod is called.
If you have:
dim a = "Michel"
myMethod(a)
msgbox("a is " & a)
and myMethod is:
Private Sub myMethod(byVal a as string)
a = "Beth"
then the message says 'a is Michel'. If 'a' is passed byRef, the message
says 'a is Beth'. When 'a' is passed byVal, then a second copy of 'a' is
created in memory, instead of a pointer to the existing variable declared
by
the caller when it's passed byRef.
Both variables would be marked (or whatever) for garbage collection when
they fell out of scope, although the ByRef variable can't be marked as
trash
when it falls out of scope in myMethod because the caller still has a
reference to it, so it will fall out of scope within the calling routine.
The 'a' passed byVal will fall out of scope within myMethod, along with
all
the other variables declared in myMethod.
So you use byVal when you want the variable to remain immutable
(unchanged,
or not mutating,) and byRef when you want the variable used as an output
parameter.
But I think you know that, so when you say:
ByRef is for when the referenced object is immutable
you're referring to the pointer being immutable, not the value. Although
I
thought pointers were always immutable, and it was just a question of
whether
or not another one gets created.
That's my understanding, anyways, but if I'm off somewhere, feel free to
let
me know.
Thanks again for your response,
-Beth
"Cor Ligthert[MVP]" wrote:
>Beth,
Adding something to the correct reply from Michel (with the exception
what I
understand of his boxing, but he tells that this is his own method, so
not
discussa ble) :-)
The ByRef is for when the referenced object is immutable. Like a string
or
an original array
Have a look at this sample code
dim a = "Michel"
myMethod(a)
Private Sub myMethod(byXXX a as string)
'Asume this method contains only
a = "Beth"
This creates a new object with a new reference.
'As the referenence is byVal to object "Michel", then that will not
change
the reference to Michel, the reference stays the same
'As you do this ByRef, then the reference which was pointing to "Michel"
will be changed to new reference to "Beth"
And the object to Michel will automaticly be removed as the Garbage
Collector starts working by instance as your video controler does some
screen refreshing while the available memory is low.
Cor.
OK, I thought when you said 'referenced object,' you were referring to an
instance of a class, not any variable in memory.
I could very well be mixing up the byVal/byRef functions from when there
were no objects, I just know if I want an output parameter, for a string or
not, I need to use byRef instead of byVal.
So your 'immutable' comment threw me, but that's ok. There's a bunch of
stuff going on under the hood I try to remain blissfully ignorant about.
Thanks again for your replies,
-Beth
"Cor Ligthert[MVP]" wrote:
The object is immutable, everytime a simple change is made in a string, a
new string is created with in fact a new reference.
That is the reason that changing a string can cost more in time and memory
than a string builder.
You are mixing up the ByVal and the ByRef from the time there were no
objects.
Cor
"Beth" <Be**@discussions.microsoft.comwrote in message
news:EA**********************************@microsof t.com...
OK, Cor, pardon my considerable ignorance, but I thought the whole
question
was what is the value of 'a' AFTER myMethod is called.
If you have:
dim a = "Michel"
myMethod(a)
msgbox("a is " & a)
and myMethod is:
Private Sub myMethod(byVal a as string)
a = "Beth"
then the message says 'a is Michel'. If 'a' is passed byRef, the message
says 'a is Beth'. When 'a' is passed byVal, then a second copy of 'a' is
created in memory, instead of a pointer to the existing variable declared
by
the caller when it's passed byRef.
Both variables would be marked (or whatever) for garbage collection when
they fell out of scope, although the ByRef variable can't be marked as
trash
when it falls out of scope in myMethod because the caller still has a
reference to it, so it will fall out of scope within the calling routine.
The 'a' passed byVal will fall out of scope within myMethod, along with
all
the other variables declared in myMethod.
So you use byVal when you want the variable to remain immutable
(unchanged,
or not mutating,) and byRef when you want the variable used as an output
parameter.
But I think you know that, so when you say:
ByRef is for when the referenced object is immutable
you're referring to the pointer being immutable, not the value. Although
I
thought pointers were always immutable, and it was just a question of
whether
or not another one gets created.
That's my understanding, anyways, but if I'm off somewhere, feel free to
let
me know.
Thanks again for your response,
-Beth
"Cor Ligthert[MVP]" wrote:
Beth,
Adding something to the correct reply from Michel (with the exception
what I
understand of his boxing, but he tells that this is his own method, so
not
discussa ble) :-)
The ByRef is for when the referenced object is immutable. Like a string
or
an original array
Have a look at this sample code
dim a = "Michel"
myMethod(a)
Private Sub myMethod(byXXX a as string)
'Asume this method contains only
a = "Beth"
This creates a new object with a new reference.
'As the referenence is byVal to object "Michel", then that will not
change
the reference to Michel, the reference stays the same
'As you do this ByRef, then the reference which was pointing to "Michel"
will be changed to new reference to "Beth"
And the object to Michel will automaticly be removed as the Garbage
Collector starts working by instance as your video controler does some
screen refreshing while the available memory is low.
Cor.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Kerry Neilson |
last post by:
Hi,
Really hung up on this one. I'm trying to get all the fields of a
dictionary to be unique for each class:
class A {
my_dict =
dict_entry = { 'key1':0, 'key2':0 }
__init__(self):
for...
|
by: amit.bhatia |
last post by:
Hi,
I have also posted this to the moderated group. I have 2 classes A and
B,
what does the following mean in header file for class A:
class A
{
class B &b;
....
};
|
by: Chris Dunaway |
last post by:
How can a class be shared between a web service and a client that consumes
the web service?
Suppose I have a Class Libraray with the following simple class:
Public Class SimpleClass
Private...
|
by: Martin Ehrlich |
last post by:
Hello NG.
I've got a little problem with sharing types between webservices and
clients.
I've created a business class with public fields within a shared assembly
like:
public class Item
{
|
by: Morten Snedker |
last post by:
How do I share a property across classes?
For example I'll have three classes:
- Settings
- Class1
- Class2
Class1 will initiate the class Settings with a New Settings and will...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
