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

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
"scottrm" <(E-Mail Removed)> wrote in message
news:F612DC7D-B942-4666-865A-(E-Mail Removed)...
>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

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


"W.G. Ryan MVP" wrote:

> 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
> "scottrm" <(E-Mail Removed)> wrote in message
> news:F612DC7D-B942-4666-865A-(E-Mail Removed)...
> >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
>
>
>

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.
"scottrm" <(E-Mail Removed)> wrote in message
news:F27D792D-26D9-4721-A9D7-(E-Mail Removed)...
> 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
>
>
> "W.G. Ryan MVP" wrote:
>
>> 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
>> "scottrm" <(E-Mail Removed)> wrote in message
>> news:F612DC7D-B942-4666-865A-(E-Mail Removed)...
>> >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
>>
>>
>>

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.

--
Scott


"W.G. Ryan MVP" wrote:

> 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.
> "scottrm" <(E-Mail Removed)> wrote in message
> news:F27D792D-26D9-4721-A9D7-(E-Mail Removed)...
> > 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
> >
> >
> > "W.G. Ryan MVP" wrote:
> >
> >> 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
> >> "scottrm" <(E-Mail Removed)> wrote in message
> >> news:F612DC7D-B942-4666-865A-(E-Mail Removed)...
> >> >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
> >>
> >>
> >>
>
>
>

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."

"=?Utf-8?B?c2NvdHRybQ==?=" <(E-Mail Removed)> wrote in
news:F612DC7D-B942-4666-865A-(E-Mail Removed):
> 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

This doesnt adreess your questino directly, but its related and you might find it useful:
http://www.codeproject.com/gen/design/TierPressure.asp

and

http://www.codeproject.com/gen/desig...inessLogic.asp


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs