business logic and data access

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

Guest

I am building an object oriented application asp.net application which is
accessing a relational database. I am a bit unclear as to the best place for
business logic to appear. My understanding (perhaps imperfect) of object
oriented methods is that the data and operations should be contained together
in business objects. This sort of suggests that data access and business
logic should be combined into the same objects. I am aware of the use of
controller objects but my understanding is that they should sequence the flow
of events of the business objects not actually contain any business logic as
such themselves. I would appreciate anyones ideas on how they stucture their
data access/business logic.
 
Scott - you can certainly do this alhough I'd avoid it. What if you have to
change a business rule? Then you have to recompile that .dll which contains
both the data access info as wella s the business info. I'd have at a
minimum 3 assemblies - one for the ui stuff, one for the business stuff and
one for the DALC stuff. To be honest, I'd actually have two more, one
BusinessInterfaces and one DalcInterfaces and make the classes MarshalByRef
objects so I could remote them if I needed to. I beleive most of the
ASP.NET starter kits have 3 tier implementations and I'd take a look at
them. http://www.knowdotnet.com/articles/goingremotei.html

HTH,

Bill
 
Thanks for the reply, problem I have with the typical 3 tier architecture is
where the controller classes in UML fit in? I guess they would be a fourth
tier, so the UI calls controller classes which in turn co-ordinate data
access and business logic classes.
 
Scott - not to quibble, I only ask to make sure we're on the same page (I
can be a bubblehead at times). But when you refer to Controller Classes in
UML - are you speaking to Design patterns and if so, then are you speaking
to the Model/View/Controller? If so, then I'm not sure there's a desing
conflict. For instance, the ASP.NET pages or Winforms are the VIew. The
Business objects as such can act as the Model. Those objects in turn (and
obviously there's a tremendous amount of flexibility here) can simply
validate the data passed to them and call the respective DALC classes to
manipulate the data.

Like I said though, there's a lot of leeway in the implementation so this
isn't hte only 'pure' way to get there. However if we aren't speaking of the
same pattern then the above is irrelevant to the discussion. Can you please
tell me a little more?

Also, if you're looking into patterns as such, remember that there are many
patterns out there and one or all aren't necessarily always the best way to
approach a problem. What I mean is that a Factory problem is excellent for
solving x specific problems, but it's not suited to certain other ones. So
ultimately, are you using this pattern across the board or is it to address
some specific areas in your design?

I'm not a pattern wonk but If you can tell me a little mroe, I can probably
be of assistance.
 
I was not really talking about design patterns as such. According to a UML
course I was on recently classes should be split into boundary(UI),
entity(data) and controller classes (I think this is part of the UML
specification). The purpose of the controller classes is to act as an
interface between the boundary and entity classes, controlling the sequence
of the program. This leaves me with the question of where to put the business
logic. Obiously not in the UI. My understanding of the controller classes is
that they just control the flow. This would not make them to my mind the best
place to put for example a complex tax calculation. This leaves me with the
question where to put such logic, the entity classes seem to be all that is
left although that does not quite seem to fit either, suggesting a fourth
layer.
 
Hi Scott,

Genrally, I think the Model/View/Controller pattern is within the UI tier.
In the UI tier, the Model is the data get from business logic tier. the
View is how data appears on the page, and we use a Controller class to map
Model to the View. So it is a different concept from tiers in an
application. Tiers are parts used in distributed systems.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top