OO design question...

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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...
Click to expand...

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.
 
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
 
Most times there is a correlation between a database entity and a business
object.

table Employee
class Employee


table Order
class Order

...

You should write a ~manager (or controller) for each class.

KEEP THE Biz Object, and the code that creates the biz object seperate.

Others may disagree, but you don't want code talking to the dal , in your
business object.
(especially the "hey, i'll grab a dataset in the constructor of my object,
and populate from there)

See my blog:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
and the 1.1 version as well.


in the above 2 examples , you would have a

EmployeeManager
OrderManager

classes, which would create single or collections of Employee or Order biz
objects.
 
Brad Pears said:
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??
Click to expand...

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.
 
sloan said:
//
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.
Click to expand...

It sounds good but it's never been the case with different datastores. Once
something is in place, then it's most likely staying the same, as an example
of going from SQL Server to Oracle. It's most likely not going to happen
that things will change. It's either one or the other that will be used. If
the back end is changing due to a different datastore being used, you got
other problems.

I am very aware of N-tier architecture with business and data access layer
objects, as I have worked in that environment as a contractor.

To separate the two adds more complexity, IMHO, particularly coming across
N-tier boundaries, but some developers will separate the boundary objects
for more security. I have used the concepts of business objects that are
smart persist them self business objects in several solutions, which can
protect them self and works very well.

http://www.lhotka.net/Article.aspx?id=1351540e-b941-446a-bacb-e0059cc82ee7
 
Back
Top