By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,472 Members | 1,204 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,472 IT Pros & Developers. It's quick & easy.

OO design question...

P: n/a
I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have read
where you should be separating the data from the business logic (i.e.
develop data classes AND business classes independantly). So does that mean
that I should really develop a class for each of the tables that I have in
SQL Server and write the appropriate methods to handle the retrieval and
updating etc.. of the data separately from a business class? Then obviously
in the business class, I would instantiate and call data class methods to do
the job...

Does that sounds about right??

Thanks, Brad
Jul 5 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Brad Pears" <br***@truenorthloghomes.comwrote in
news:OR**************@TK2MSFTNGP06.phx.gbl:
I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have
read where you should be separating the data from the business logic
(i.e. develop data classes AND business classes independantly). So
does that mean that I should really develop a class for each of the
tables that I have in SQL Server and write the appropriate methods to
handle the retrieval and updating etc.. of the data separately from a
business class? Then obviously in the business class, I would
instantiate and call data class methods to do the job...
That sounds like a data layer.

You can avoid writing all that code by using a OR/M mapper like LLBLGen Pro
or Codesmith :-) It's very tedious to write.
Jul 5 '07 #2

P: n/a

"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:OR****************@TK2MSFTNGP06.phx.gbl...
>I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have read
where you should be separating the data from the business logic (i.e.
develop data classes AND business classes independantly). So does that
mean that I should really develop a class for each of the tables that I
have in SQL Server and write the appropriate methods to handle the
retrieval and updating etc.. of the data separately from a business class?
Then obviously in the business class, I would instantiate and call data
class methods to do the job...

Does that sounds about right??
Yes, that's correct in the traditional sense. There is also the business
object that persist itself to that database too. The business object has the
database code in it as well, along with the business logic.

Jul 5 '07 #3

P: n/a
//
The business object has the
database code in it as well, along with the business logic.//

That is one way to do it.

Personally I prefer to seperate the code of the business object, and the
code that creates the business object.
One day, you might have different datastores for your objects.
Keeping the 2 ideas seperate gives you more flexibility.

See:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:eB**************@TK2MSFTNGP04.phx.gbl...
>
"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:OR****************@TK2MSFTNGP06.phx.gbl...
I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have
read
where you should be separating the data from the business logic (i.e.
develop data classes AND business classes independantly). So does that
mean that I should really develop a class for each of the tables that I
have in SQL Server and write the appropriate methods to handle the
retrieval and updating etc.. of the data separately from a business
class?
Then obviously in the business class, I would instantiate and call data
class methods to do the job...

Does that sounds about right??

Yes, that's correct in the traditional sense. There is also the business
object that persist itself to that database too. The business object has
the
database code in it as well, along with the business logic.

Jul 5 '07 #4

P: n/a
Take a look at
http://msdn.microsoft.com/vstudio/ex.../learningpath/

and look at "windows path" , last lesson 12 thru 16.

Its videos...but he codes one thing one way..and then separates out the
class properly.

When i watched it, i thought it was a good simple example

Miro
"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:OR****************@TK2MSFTNGP06.phx.gbl...
>I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have read
where you should be separating the data from the business logic (i.e.
develop data classes AND business classes independantly). So does that
mean that I should really develop a class for each of the tables that I
have in SQL Server and write the appropriate methods to handle the
retrieval and updating etc.. of the data separately from a business class?
Then obviously in the business class, I would instantiate and call data
class methods to do the job...

Does that sounds about right??

Thanks, Brad

Jul 6 '07 #5

P: n/a
Thanks, I'll check it out...

Brad
"Miro" <mi******@golden.netwrote in message
news:e7**************@TK2MSFTNGP02.phx.gbl...
Take a look at
http://msdn.microsoft.com/vstudio/ex.../learningpath/

and look at "windows path" , last lesson 12 thru 16.

Its videos...but he codes one thing one way..and then separates out the
class properly.

When i watched it, i thought it was a good simple example

Miro
"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:OR****************@TK2MSFTNGP06.phx.gbl...
>>I am really new to OO design and development pricipals and have a
question...
When developing vb.net applications using OO design principals I have
read where you should be separating the data from the business logic
(i.e. develop data classes AND business classes independantly). So does
that mean that I should really develop a class for each of the tables
that I have in SQL Server and write the appropriate methods to handle the
retrieval and updating etc.. of the data separately from a business
class? Then obviously in the business class, I would instantiate and call
data class methods to do the job...

Does that sounds about right??

Thanks, Brad


Jul 6 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.