Sharing an instance of an object across classes

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
news:A6BC7C3C-AFBF-4862-A20E-800CA57E8F70@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
news:5313B572-3B67-4DFB-B552-49D057C28B15@mi crosoft.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]

Re: Sharing an instance of an object across classes

The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvi der.

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" <Beth@discussio ns.microsoft.co mwrote in message
news:68B05C5E-E72E-44DF-B276-6120E4BE64BC@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
>news:A6BC7C3 C-AFBF-4862-A20E-800CA57E8F70@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
>news:5313B57 2-3B67-4DFB-B552-49D057C28B15@mi crosoft.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.

>>
>>
>>

[Cor Ligthert[MVP]]

Re: Sharing an instance of an object across classes

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.inform ation
End Get
End Property

Public Function WeekSalary(ByVa l 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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:4C1523D6-267C-42D4-A3F7-A51EC00DDB88@mi crosoft.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" <Beth@discussio ns.microsoft.co mwrote in message
>news:513683F 2-1DEE-4565-9C4A-8642B4CD024F@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
>news:8D42B0F 4-6D5C-4A5F-B32A-330F97A7B8C0@mi crosoft.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 bDebuggerAttach ed As Boolean)
Dim sServer As String
Dim sDB As String
>
If bDebuggerAttach ed Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
>
m_sConnect = "Data Source=" & sServer & ";Database= " & sDB &
";Integrate d
Security=true"
m_sConnect = m_sConnect & ";Applicati on Name = " &
My.Application. Info.AssemblyNa me
>
m_objSQLClient = New clsSQLClient
m_objSQLClient. connect(m_sConn ect)
>
m_objUsers = New clsUsers(m_objS QLClient)
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("u sers")
>
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.sqlClien t.tableForEdit( "users")
>
but it doesn't work- it raises an exception when clsUsers.markEn try
references mybase.sqlClien t.
>
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
>>
>>
>>

>>
>>
>>

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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
MembershipProvi der.
>
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" <Beth@discussio ns.microsoft.co mwrote in message
news:68B05C5E-E72E-44DF-B276-6120E4BE64BC@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
news:A6BC7C3C-AFBF-4862-A20E-800CA57E8F70@mi crosoft.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.space s.live.com/Blog/cns!A68482B9628 A842A!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" <Beth@discussio ns.microsoft.co mwrote in message
news:5313B572-3B67-4DFB-B552-49D057C28B15@mi crosoft.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.
>
>
>

>
>
>

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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 ,

[Andrew Morton]

Re: Sharing an instance of an object across classes

sloan wrote:

The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvi der.
>
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

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co m wrote in message
news:8D42B0F4-6D5C-4A5F-B32A-330F97A7B8C0@mi crosoft.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 bDebuggerAttach ed As Boolean)
Dim sServer As String
Dim sDB As String
>
If bDebuggerAttach ed Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"
>
m_sConnect = "Data Source=" & sServer & ";Database= " & sDB & ";Integrate d Security=true"
m_sConnect = m_sConnect & ";Applicati on Name = " & My.Application. Info.AssemblyNa me
>
m_objSQLClient = New clsSQLClient
m_objSQLClient. connect(m_sConn ect)
>
m_objUsers = New clsUsers(m_objS QLClient)
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("u sers")

[Michel Posseth]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

[Michel Posseth]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

[Michel Posseth]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

[Michel Posseth]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

[Cor Ligthert[MVP]]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mwrote in message
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mschreef in bericht
news:275A88A7-38F2-4199-A094-AAD4FAF52C4A@mi crosoft.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 ,

>
>

[=?Utf-8?B?QmV0aA==?=]

Re: Sharing an instance of an object across classes

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.

[Cor Ligthert[MVP]]

Re: Sharing an instance of an object across classes

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" <Beth@discussio ns.microsoft.co mwrote in message
news:EA9AE1B6-6193-41B0-B21E-D1278C7F3A0E@mi crosoft.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.