[OT] Business Layer Ideas

[David Whipple <dw...@dtcc.com>]

This is an off topic post, but there seem to be a lot of people with good
opinions here.

I am trying to provide a framework (based on Stuts and Spring) for our
company
to use.  I'd like to make a reinforcement of the business layer in
applications.

We do not use EJBs, so a lot of the patterns that are out there do not seem
to
apply.  I have not been able to find any references I like.

The goal is to encourage better program design and development by
having a clear definition of what are the business objects in the program.

We want to come up with a way through patterns to help programmers avoid
poor
programming practices.  Clear separation into layers is one basic idea
behind
this.  We want to come up with some interface to the business layer which
will
force programmers to know what are to be the business objects in their
architecture.

Does anyone have any ideas and/or know of any references for this?

Thanks,
Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Ted Husted <te...@gmail.com>]

On 5/27/05, Duong BaTien <du...@gmail.com> wrote:
> We use Chain of Responsibility (CoR) implemented by commons-chain and
> its Agility to construct a Request/Response framework to connect a
> request to its designated service, whether the designated service is in
> a web-application service container, a portlet container, auth for
> authentication/authorization, or a Jcr container. 

I'm also finding that, for my applications, a service orientated
architecture based on a Chain of Responsibility works quite well. I've
started work on a framework that pushes a lot of what we do now in
Struts into the business layer. It's in C# now, because that what we
are using at work, but it's all plain old objects and should be an
easy port back to Java.

* http://wiki.apache.org/struts/StrutsOverDrive

We're using a nearly-complete prototype at work, so I've a good handle
on where this is going. It's just hard to find the time to clean it up
for public consumption :)

The essential idea is that the presentation tier should focus on
collecting and display values, and leave the rest to the business
layer. Right now, a lot of us slide down a slipperly slope that pushes
too much code into the presentation layer, where it is difficult to
test. And, by test, I really mean "share with other presentation
layers". Unit tests are a presentation layer too :)

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Duong BaTien <du...@gmail.com>]

On Fri, 2005-05-27 at 16:00 -0400, David Whipple wrote:
> This is an off topic post, but there seem to be a lot of people with good
> opinions here.
> 
> I am trying to provide a framework (based on Stuts and Spring) for our
> company
> to use.  I'd like to make a reinforcement of the business layer in
> applications.
> 
> We do not use EJBs, so a lot of the patterns that are out there do not seem
> to
> apply.  I have not been able to find any references I like.
> 
> The goal is to encourage better program design and development by
> having a clear definition of what are the business objects in the program.
> 
> We want to come up with a way through patterns to help programmers avoid
> poor
> programming practices.  Clear separation into layers is one basic idea
> behind
> this.  We want to come up with some interface to the business layer which
> will
> force programmers to know what are to be the business objects in their
> architecture.
> 
> Does anyone have any ideas and/or know of any references for this?
> 
> Thanks,
> Dave
> 
Greetings:

We use Chain of Responsibility (CoR) implemented by commons-chain and
its Agility to construct a Request/Response framework to connect a
request to its designated service, whether the designated service is in
a web-application service container, a portlet container, auth for
authentication/authorization, or a Jcr container. At the business layer,
the designated service may use other services in other containers. e.g.
the personalization of auth container uses UserDaoImpl of DAO container.

We use Spring IoC to assemble chain Catalogs and their commands. Hence
the request/response framework is based on CoR/IoC integrated with your
presentation engine at the front. We use Jsf+Tiles as our presentation
engine.

The good thing is that available infrastructure takes care of detailed
connections while isolating the dependencies of itemized services within
1 container and among containers. Developers just need to plug in the
required specified functionality based on design contract.

We integrate the Request/Response with workflow using Shale Dialog and
Spring WebFlow to produce Request/Response/Workflow Business Application
Framework.

More detailed discussion is in the following link, which will be updated
by 2nd week of June after the release of RedHat Fedora 4.

http://www.dbgroups.com/docs/architecture.html#BusinessApplicationsFramework


Hope this may help.

BaTien
DBGROUPS

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Dakota Jack <da...@gmail.com>]

http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764558315,descCd-download_code.html

On 5/27/05, David Whipple <dw...@dtcc.com> wrote:
> This is an off topic post, but there seem to be a lot of people with good
> opinions here.
> 
> I am trying to provide a framework (based on Stuts and Spring) for our
> company
> to use.  I'd like to make a reinforcement of the business layer in
> applications.
> 
> We do not use EJBs, so a lot of the patterns that are out there do not seem
> to
> apply.  I have not been able to find any references I like.
> 
> The goal is to encourage better program design and development by
> having a clear definition of what are the business objects in the program.
> 
> We want to come up with a way through patterns to help programmers avoid
> poor
> programming practices.  Clear separation into layers is one basic idea
> behind
> this.  We want to come up with some interface to the business layer which
> will
> force programmers to know what are to be the business objects in their
> architecture.
> 
> Does anyone have any ideas and/or know of any references for this?
> 
> Thanks,
> Dave
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Dakota Jack <da...@gmail.com>]

I should have added that Rod (Johnson) in the book cited pointedly
advocates extensive use of the Strategy Pattern, see pp. 421 ff.  The
use of CoR in Struts 1.3 for the extensible RequestProcessor is not a
feature but is a way of solving the problem created by the original
use of the Template Method Pattern in that context.  Had the Strategy
Pattern been used in the first instance, everything would have worked
better, in my opinion.  In many ways, I think in the future the
Template Method Pattern may be seen as an Anti-Pattern.

Just to forestall flamethrowers, I want to emphasize that others
probably think differently and even the "majority", i.e. by definition
the members ipsa facto of the "meritocracy", may think differently. 
But, Rod Johnson is no slouch on these matters.  He thinks the use of
Strategy Pattern is "one of the reasons [Spring] is such a flexible
and extensible framework".

On 5/27/05, David Whipple <dw...@dtcc.com> wrote:
> This is an off topic post, but there seem to be a lot of people with good
> opinions here.
> 
> I am trying to provide a framework (based on Stuts and Spring) for our
> company
> to use.  I'd like to make a reinforcement of the business layer in
> applications.
> 
> We do not use EJBs, so a lot of the patterns that are out there do not seem
> to
> apply.  I have not been able to find any references I like.
> 
> The goal is to encourage better program design and development by
> having a clear definition of what are the business objects in the program.
> 
> We want to come up with a way through patterns to help programmers avoid
> poor
> programming practices.  Clear separation into layers is one basic idea
> behind
> this.  We want to come up with some interface to the business layer which
> will
> force programmers to know what are to be the business objects in their
> architecture.
> 
> Does anyone have any ideas and/or know of any references for this?
> 
> Thanks,
> Dave
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Dakota Jack <da...@gmail.com>]

One last note, on a somewhat experimental basis, I have been building
an application, which for the lack of a better idea I call
"StrutsState", for state management issues in or relating to the
business layer which is stored in the servlet context (application)
layer.  This application interfaces with page, request, and session
state management but provides much finer management of persistence. 
While nothing is written in stone in this application, I have found it
useful to separate concerns generally into (a) navigation and (b) data
areas.  Both the navigation and data areas feed JSTL but in a standard
way such that the JSTL can be written with logical rather than
physical references.  If any of this interests you, which I suppose is
unlikely in your circumstance, please feel free to email me directly.

On 5/27/05, David Whipple <dw...@dtcc.com> wrote:
> This is an off topic post, but there seem to be a lot of people with good
> opinions here.
> 
> I am trying to provide a framework (based on Stuts and Spring) for our
> company
> to use.  I'd like to make a reinforcement of the business layer in
> applications.
> 
> We do not use EJBs, so a lot of the patterns that are out there do not seem
> to
> apply.  I have not been able to find any references I like.
> 
> The goal is to encourage better program design and development by
> having a clear definition of what are the business objects in the program.
> 
> We want to come up with a way through patterns to help programmers avoid
> poor
> programming practices.  Clear separation into layers is one basic idea
> behind
> this.  We want to come up with some interface to the business layer which
> will
> force programmers to know what are to be the business objects in their
> architecture.
> 
> Does anyone have any ideas and/or know of any references for this?
> 
> Thanks,
> Dave
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Business Layer Ideas

[Dakota Jack <da...@gmail.com>]

A really wonderful book is J2EE Development without EJB by Rod
Johnson, the original architect for Spring.    On the whole, however,
outside the issues associated with EJBs, there is a dirth of buisness
layers patterns, so far as I know.  I think some thought about
developing a separate framework for the business layer alone would be
worthwhile.  I have been thinking and trying to get discussion going
on this a long time.  I like the way you think.

On 5/27/05, David Whipple <dw...@dtcc.com> wrote:
> This is an off topic post, but there seem to be a lot of people with good
> opinions here.
> 
> I am trying to provide a framework (based on Stuts and Spring) for our
> company
> to use.  I'd like to make a reinforcement of the business layer in
> applications.
> 
> We do not use EJBs, so a lot of the patterns that are out there do not seem
> to
> apply.  I have not been able to find any references I like.
> 
> The goal is to encourage better program design and development by
> having a clear definition of what are the business objects in the program.
> 
> We want to come up with a way through patterns to help programmers avoid
> poor
> programming practices.  Clear separation into layers is one basic idea
> behind
> this.  We want to come up with some interface to the business layer which
> will
> force programmers to know what are to be the business objects in their
> architecture.
> 
> Does anyone have any ideas and/or know of any references for this?
> 
> Thanks,
> Dave
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org