G
Guest
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.
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.
B
Brad Pears
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
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
S
sloan
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.
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.
M
Mr. Arnold
Brad Pears said:
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.
S
sloan
//
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
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
M
Mr. Arnold
sloan said:
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
M
Miro
Take a look at
http://msdn.microsoft.com/vstudio/express/beginner/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
http://msdn.microsoft.com/vstudio/express/beginner/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
B
Brad Pears
Thanks, I'll check it out...
Brad
Brad
Miro said: