Best Practice for Organizing Business Logic code for large applications

[Mitesh Gajjar]

For large applications what is the best practice to organize the code
in Model for business logic? I have not come across any specific
suggestion to organize the code in any blog, forum or document so I
decided to present my thoughts please let me know the pros and cons.

Then default approach is to put all business logic code in
AppModuleImpl so we can easily access the VO instances and/or call
database APIs. Over long term as business logic continues to be added/
modified, the AppModuleImpl will become too large and consequently
increase code lookup and maintenance difficulty. Over time, it can
result in code fragmentation and become difficult to ensure business
logic of closely related functionality is placed together. (separate
issue: when editing the file JDeveloper IDE response to keystrokes
becomes slower as the file gets larger, we have a VORowImpl file >
200KB when editing the file the response is slow).

As sample case I will use a guest checkin routine for hotel. To
achieve that we have following methods:

1. checkInReservation() - public method exposed in the Client
Interface of the AM.
2. getAvailableRoom() - private method invoked by checkInReservation
()
3. getGuestId() - private method invoked by checkInReservation
()
4. checkIn() - private method invoked by checkInReservation
()

First Approach:
_______________

The way I want to organize this code is similar to below:

1. Reservation.java - Interface

public interface Reservation {
public void checkInReservation(Number reservationId, String
guestId);
}

2. ReservationBase.java - Base class containing business logic &
constructor with AM instance.

import xyz.model.am.ReservationServiceImpl;

public class ReservationBase{

protected ReservationServiceImpl am = null;

/* constructors */
public ReservationBase()
{
}

public ReservationBase(ReservationServiceImpl am) {
this.am = am;
}
public void checkInReservation(Number reservationId, String
guestId) {
String room = getAvailableRoom(); // Gets the next
available room in the hotel.
Number guestId = getGuestId(guestName); // Gets the
nameId of the Guest.
checkIn(reservationId, guestId, room); // Checks in the
reservation.
}

private String getAvailableRoom(){
String room;
//Business logic here. View objects, DB APIs, etc can be
accessed by using AM instance (am).
return room;
}

private Number getGuestId(String guestName){
Number num;
//Business logic here. View objects, DB APIs, etc can be
accessed by using AM instance (am).
return num;
}

private void checkIn(Number reservationId, Number guestId,
String room){
//Business logic here. View objects, DB APIs, etc can be
accessed by using AM instance (am).
}

}

3. ReservationUser.java - Extends base class ReservationBase.java and
implements interface Reservation.java. Exception handler/Logger.

import xyz.model.am.ReservationServiceImpl;
import oracle.jbo.JboException;

public class ReservationUser extends ReservationBase implements
Reservation{

public ReservationUser() {
super();
}

public ReservationUser(ReservationServiceImpl
reservationServiceImpl) {
super(reservationServiceImpl);
}

@Override
public void checkInReservation(Number reservationId, String
guestId) {
try {
super.checkInReservation(reservationId, guestId);
} catch(Exception ex) {
//Add Logger code
throw new JboException(ex);
}
}
}

4. ReservationServiceImpl.java - Application Module class file

import xyz.model.src.Reservation;
import xyz.model.src.ReservationUser;

public class ReservationServiceImpl extends ApplicationModuleImpl
implements ReservationService {

public void checkInReservation(Number reservationId, String
guestId) {
Reservation r = new ReservationUser(this); //Instantiate
the class with the application module instance
return r.checkInReservation(reservationId, guestId);
}
}

A potential problem here is the circular dependency where Reservation
& ReservationUser refer to ReservationServiceImpl and
ReservationServiceImpl refers to Reservation & ReservationUser.

The advantage is that the code for business services is grouped into
separate classes per functionality and the AMImpl contains only those
methods that need to be exposed to the Client Interface.

Second Approach:
_______________

The other approach is to have the business logic in AppModuleImpl but
have several AppModules for each business operations. All the
AppModules will be nested in a Root AppModule and in the View
controller, the task flow properties will have requires-transaction
(Use existing transaction if possible) and shared data-control.

The disadvantage is that for a very large application this could
result in too many AppModules resulting in maintenance/coding
difficulty.

Can you please suggest pros and cons of this approach and if there is
any other approach you are using for your projects.

Thanks
Mitesh

[Chris Muir]

Hi Mitseh

I'd hate to see such a long detailed post go un-answered on the ADF
EMG - nice work.

In your first approach, I see what you're attempting to achieve here,
though I can see you come from a Java background with a lot more
experience than I, as you've kind of flipped the BC usage on it's head
(for me at least). You've created a bunch of classes (ie.
Reservations) that make use of the ADF BC classes rather than building
your BCs to reflect the model (if that makes sense)

As example (and at an incredibly shallow and not thought solution - I
know you'll have infinite more ideas about you're business domain as
you've thought about it for a long time), I would be putting the
checkInReservation() in a the Reservation VOImpl, making calls out to
the AvailableRooms VO to retrieve the next available room, and a
further call to Guest VO with a bind param :guestId (as equivalent to
the getAvailableRoom() and getGuideId() methods respectively). So in
my solution the BC components are designed to support the
checkInReservation() method, not used by external classes. Again just
an approximation of how I initially would think of building it (all of
5 minutes), but with no real indepth "thinking".

Hopefully other members are willing to take on the challenge of giving
them your thoughts about your problem description.

Cheers,

CM.

2010/1/26 Mitesh Gajjar <mit...@gmail.com>:

> --
> You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
>

--
Chris Muir

Oracle Systems Consultant & Trainer
SAGE Computing Services Pty Ltd
http://www.sagecomputing.com.au

Oracle ACE Director
http://www.oracle.com/technology/community/oracle_ace/index.html

Email: chris...@sagecomputing.com.au
Blog: http://one-size-doesnt-fit-all.blogspot.com/
Mobile/Cell: 043-828-6421
International: +61-43-828-6421
Gmail chat: chris...@gmail.com
Twitter: twitter.com/chriscmuir
LinkedIn: http://www.linkedin.com/in/chriscmuir

[Marcos Ortega]

Hi there;

   My solution, would pass trough stored procedures ( or packages ) , quite as the first aproche from Mitseh, but I prefer oracle packages;

   My AppDataModule would have callers to those packages; exposing quite the same api to viewControler, and  with none (or the minimum) kind of  java class hierarquies ;

   In some cases there should be views like ( allTheFreeRooms ) , Oracle views having bc4j views against then;

      Marcos Ortega
 Analista de Sistemas
  Campo Grande - MS
http://www.santoandrea.com.br

2010/1/28 Chris Muir <chris...@gmail.com>

[Mitesh Gajjar]

Thank you Chris and Marcos. I appreciate your comments.

Chris and others I want to make it clear that I will consider myself
very lucky if I can accumulate just a fraction of the knowledge you
have. :)

Originally I have Forms background we are currently in process of
migrating from Forms to ADF using Fusion stack & WS.

Marcos, though in most cases we can make calls the DB packages keeping
buss logic in DB I think there will be situations where we will have
to write buss logic in the Model/Business Layer for e.g. when we are
in middle of a transaction and those rows are not commited to the DB
yet. We may need to take a hybrid approach by keeping some logic in DB
packages and some in the Model Layer. As such, I am going with the
assumption that we will not be able to avoid adding buss logic in the
Model Layer.

Do we have any suggested best practices for organizing business logic
in Model/Business Layer?

It seems to me that the implicit guidance is to put the business logic
in AppModuleImpl and expose the desired methods to Client Interface.
My concern is that over time this would make AppModuleImpl too large
to easily maintain code as we keep on adding new methods & sub-
methods.

Approach 1)

One approach is to come up with a best practice to modularize
functionally related code into classes (similar to PLSQL database
packages). We would pass AM instance in the class constructor so the
methods in the class will have access to VOs,etc of the AM.

AppModuleImpl would call methods from various classes(which contain
the buss logic). This will enable an uncluttered AMModuleImpl having
only methods that are going to be exposed to Client Interface.

Approach 2)

Another approach is to keep business logic in AppModuleImpl and
have several AMs for each business operations.
Create a Root AM and nest all related AMs to the Root AM so they can
share same transaction.

In the View layer, we set the task flow properties to requires-

transaction
(Use existing transaction if possible) and shared data-control.

I am interested to know how you organize business logic in your
current applications and your opinions in what is the best practice.
And any pros and cons of either approach.

Thanks
Mitesh.

[Tran Duc Minh]

Hi,

I agree with Marcos, I'll try my best to put all the "business" inside
the database where application can benefit from performance. AM will
have methods that invoke those stored procedures and functions in the
model.

Implement solution this way, we will not have to change the View layer
whenever business changes. I have some pains when doing nearly all the
businesses at the view layer, i.e. query. When business changes or
customer asked for some performance tunning, I have to tune only the
queries that are organized in packages.

This way, when we have to release some patches, just provide
customers' DBA a .bat file that runs all the updates for the packages
in database. Of course when there are the needs to change the UI, we
still have to do some XHTML modification, but most of the times,
customer concerned about performance as well as business requirements.

In J2EE world, our projects can benefit from writing just simple
classes so we can focus on keeping our application run like charm.
______________
|Trần Đức Minh \___________________________
| Software Engineering in Management Dept. |
| Institute Of Information Technology. |
| VAST - 18 Hoang Quoc Viet - Cau Giay - HN|
| Phone: 756 2293 - 0903 202702 |
| Email: duc...@ioit.ac.vn |
|__________________________________________|

>> adf-methodolo...@googlegroups.com<adf-methodology%2Bunsu...@googlegroups.com>

>> >
>>
>>
>>
>> --
>> Chris Muir
>>
>> Oracle Systems Consultant & Trainer
>> SAGE Computing Services Pty Ltd
>> http://www.sagecomputing.com.au
>>
>> Oracle ACE Director
>> http://www.oracle.com/technology/community/oracle_ace/index.html
>>
>> Email: chris...@sagecomputing.com.au
>> Blog: http://one-size-doesnt-fit-all.blogspot.com/
>> Mobile/Cell: 043-828-6421
>> International: +61-43-828-6421
>> Gmail chat: chris...@gmail.com
>> Twitter: twitter.com/chriscmuir
>> LinkedIn: http://www.linkedin.com/in/chriscmuir
>>
>> --
>> You received this message because you are subscribed to the ADF
>> Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to

>> adf-methodolo...@googlegroups.com<adf-methodology%2Bunsu...@googlegroups.com>

[Marcos Ortega]

A Friend of mine, uses other approche;

   He advogate that all busines inteligence must be outside of any framework ( ADF, SPRING .. and so one ) , so he heavilly uses  UML  diagrams , and all his classes came from "Object class"

  In His point of view,  he is not tied to any framework any more, he can change the view / controler / model and just re-acoplate to the new one;

  I personally desagree, because he never will use all the power ( and advantages ) of hi's selected view/ controler / model framework

 

      Marcos Ortega
 Analista de Sistemas
  Campo Grande - MS
http://www.santoandrea.com.br

2010/1/29 Tran Duc Minh <tduc...@gmail.com>

[Michael Koniotiakis]

I feel that puting all bussiness logic in database is far away from
j2ee architecture and ADF.
I understand that many people (as myself) comes from Forms and PL/SQL
backround and feel easier to put and organise the code there.

Yet ADF is a framework that provides numerus declarative easy ways to
put your bussiness logic in middle tier.
I understand that if the business logic is. 'When user press buttons
all invoices must be computed' to do it with a database procedure.
But most of rules conserning few rows of related data can be applied
easyer in ADF BC.
Security and Validations in Entity objects
List of values and view criteria in View objects
Master detail relations and any custom logic in AppModule.
Navigation and visualisation rules in TaskFlows and pages
You can also add custom logic in Entities and View java classes or
base classes for generalisation.

You may feel like this way you split your business logic and you will
not be able to find where you put what.
In the database logic we use to gather business logic in packages. In
adf we gather them in model projects.
But actualy since you are in the same project with the same package
structure, everything is in 1 package. You just need to set rules of
what logic you put in what class and you have many ways to find your
code later.

To decide about how many and what AM to create you need to analyse the
logic in use cases.
I feel like every usecase that can be executed indipendently (of other
usecases) can be a diferent application module. I dont think there is
a need for Application Modules to share the same trunsaction if the
use case does not need same trunsaction.
i.e. reservation, checkin, checkout will probably be diferent use
cases that will happen indipendently and they dont need to be in the
same application module

On Jan 29, 7:36 pm, Tran Duc Minh <tducm...@gmail.com> wrote:
> Hi,
>
> I agree with Marcos, I'll try my best to put all the "business" inside
> the database where application can benefit from performance. AM will
> have methods that invoke those stored procedures and functions in the
> model.
>
> Implement solution this way, we will not have to change the View layer
> whenever business changes. I have some pains when doing nearly all the
> businesses at the view layer, i.e. query. When business changes or
> customer asked for some performance tunning, I have to tune only the
> queries that are organized in packages.
>
> This way, when we have to release some patches, just provide
> customers' DBA a .bat file that runs all the updates for the packages
> in database. Of course when there are the needs to change the UI, we
> still have to do some XHTML modification, but most of the times,
> customer concerned about performance as well as business requirements.
>
> In J2EE world, our projects can benefit from writing just simple
> classes so we can focus on keeping our application run like charm.
>  ______________
> |Trần Đức Minh \___________________________
> | Software Engineering in Management Dept. |
> | Institute Of Information Technology.     |
> | VAST - 18 Hoang Quoc Viet - Cau Giay - HN|
> | Phone: 756 2293 - 0903 202702            |

> | Email: ducm...@ioit.ac.vn                |

> |__________________________________________|
>
> On Fri, January 29, 2010 17:56, Marcos Ortega said:
>
>
>
> > Hi there;
>
> >    My solution, would pass trough stored procedures ( or packages ) ,
> > quite
> > as the first aproche from Mitseh, but I prefer oracle packages;
>
> >    My AppDataModule would have callers to those packages; exposing quite
> > the
> > same api to viewControler, and  with none (or the minimum) kind of  java
> > class hierarquies ;
>
> >    In some cases there should be views like ( allTheFreeRooms ) , Oracle
> > views having bc4j views against then;
>
> >       Marcos Ortega
> >  Analista de Sistemas
> >   Campo Grande - MS
> >http://www.santoandrea.com.br
>

> > 2010/1/28 Chris Muir <chriscm...@gmail.com>

> >> adf-methodolo...@googlegroups.com<adf-methodology%2Bunsubscribe@­googlegroups.com>

>
> >> --
> >> Chris Muir
>
> >> Oracle Systems Consultant & Trainer
> >> SAGE Computing Services Pty Ltd
> >>http://www.sagecomputing.com.au
>

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

[Jang Vijay Singh]

Hi Mitesh, 

I, being from a Java background, am pleased to see you giving active consideration to a different paradigm (from your own Forms one) and doing a good job of it. 

I agree with Chris Muir's viewpoint about ADFbc components being the primary drivers of any business functionality (in an app that uses ADFbc, that is) - other utility classes should be used by ADFbc to support some operations rather than the other way round. 

Also, based on my own superficial, instant 'design' (which is just meant to illustrate my design approach and not meant to force down your throat;  which I also see as a 'natural' ADF design <opinions invited from the group on this>), I wouldn't think in terms of master and transaction table, but rather:

-What the business domain objects are and which ones would be used in a given usecase / user interaction/ transaction (loosely related in this context) and by whom (guest, hotel staff, robot calling your web service) 

I can see your user interactions consisting of 'search availability', 'create reservation', 'checkin' as 3 taskflows. 

Search taskflow would be without a 'transaction' enabled, while the reservationcreation / checkin flows would have transactions enabled (i.e. user is changing information that needs to be persisted). search and reservation would have shared data control scopes. 

Business Domain Objects: Hotel, Reservation, Availability

And here's how I see the ADFbc services one would need to support the above user interactions. 

- The ReservationAM could be used to drive all the above flows: 

It would contain the object hierarchy (master-detail relationship / view link coordinated) of all the view objects needed in that closely related set of transactions.  

Something like AvailabilityVO (based on HotelEO e.g.) (Searchable in a non-transactional context in the search TF)

-> ReservationVO nested under it (when user clicks on an availability and goes to create reservation flow, they have created a 'reservation' for that availability - they could now 'commit' or 'rollback')

For the checkin flow:

- A user logs in and finds their reservation and manually performs a 'checkin' <- checkIn method called by UI

- Checkin is done automatically <- 'checkin' operation called via its ReservationAM's Service interface

- A hotel employee does a manual checkin for the user <- ReservationAM::checkin called by UI meant for staff via ReservationAM nested under HotelReservationsAM

Now, 'inside' checkin, how/where you organise your code wouldn't matter -

Things I watch out for are the very basics: 

- Single giant 'methods' of more than 100 lines 

- Same lines of code repeated in multiple places (rather small neat operations that perform a single thing)

You should definitely use utility classes to organize common pieces of code - but most commonly it's a symptom of not enough reuse. 

I'm not in favour of putting them in the database but that should go in a separate mail..

Jang Vijay Singh

Thanks
Mitesh.

[Jang Vijay Singh]

Hi Tran Duc Minh and Marcos Ortega, 

I'm separately addressing the motivation behind having 'business logic' in the database here. 

Let me please also state at first that my views are mostly with reference to design of new applications that have chosen to use ADF (and similar OR/M) technologies to build their model or business services. 

I understand there can be strong business sense in reusing existing investment in PL/SQL - this includes existing skill sets (it seems more developers are comfortable with the procedural approach than those who appreciate a more object oriented one). 

Let me also first reiterate a few ideals that (i think) we seek:

1) Separation of view from model and business logic

2) The DRY rule - don't repeat yourself - done easier in a more object oriented middle tier technology.

3) Let the middle tier memory handle all complex operations that the user *waits on* and isolate user interactions from database latency - data retrieval and writes (caching and deferred writes complete the picture here - but i'm not certain how they work in ADF)

>1. I'll try my best to put all the "business" inside

>the database where application can benefit from performance.

How much faster can you get than application server memory? On the other hand, the same logic in the database might add scalability issues (e.g. when you create a mid-tier cluster to accommodate greater load, the database will continue to be a bottleneck)

Business operations should need to hit the database for large data access/writes once in a while (preferably behind the scenes, with deferred writes - i am not sure of this specific function in ADFbc). 

Role of the database *now* (in the age of applications that are middletier heavy), as I see it, is just as a persistent store of data. 

Finally, as Michael Koniotiakis put it:

>You may feel like this way you split your business logic and you will
>not be able to find where you put what.

Regarding Tran Duc Minh's point:

> Implement solution this way, we will not have to change the View layer

>whenever business changes.

If clear MVC separation is maintained in your applications, you shouldn't  have to change your view layer every time business tier or model changes (unless you mean you can change and redeploy your PL/SQL quicker than redeploying an application/business services? I would seek the group's opinion on this one.) 

Regards, 

Jang Vijay Singh

You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

[Trần Đức Minh]

Hi Jang Vijay Singh,

>>How much faster can you get than application server memory? 

As my experiences, mostly come from my Forms skill, it help us avoid commonly mistakes when writing Java code accessing database such as using bind variables. It is best to find a way to let developer, without much knowledge in how database works, follow this best practice when develop database-backed applications. 

I totally disagree with your point: "... database is just as a persistent store of data. " since if we design our applications without aware of database capabilities, we might face the problems like:

+ hard to tune our applications for performance when problems come from bad design in database.

+ reinvent the wheel, I mean, we creates some stuffs to do the job without knowing that database can do it already.

>> If clear MVC separation is maintained in your applications, you shouldn't  have to change your view layer every time business tier or model changes (unless you mean you can change and redeploy your PL/SQL quicker than redeploying an application/business services? I would seek the group's opinion on this one.) 

Yes I mean we can change and redeploy our PL/SQL packages quicker than redeploying an application/business services. I made a mistake when talking about changing view layer when business changes. It was model, middle tier, coming in my mind.

In some circumstances, MVC help us efficiently separate view from the model and our application scale well. It is helped by using OO way and I have no disagreement with this approach. My point is, it is not useful when we try to distinguish procedural and OO approaches when develop application. They are just the ways to accomplish our task: meet the customers' needs. They care only if application apply exactly what they wanted and in some degree, help them improve their businesses.

Regards,

2010/1/30 Jang Vijay Singh <jvs...@gmail.com>

--
TRẦN ĐỨC MINH

Software Engineering in Management Dept.

Institute of Information Technology
18 Hoang Quoc Viet – Cau Giay – Ha noi
Phone: 0903202702
Email: duc...@ioit.ac.vn

[Aino]

Yes, the never-ending discussion about where to put business logic :-). 

I'm personally not so 'rigid' about the definition of the J2EE architecture. The (logical) business tier (the model) may be implemented in more than one technical locations and the database may be one of them. 

One thing for sure is that often the data is the most important asset. So we must make sure that we protect our data, make sure it's consistent and that the correct business rules are applied to it. If possible, we should do that as near to the data as possible: the database. In addition, it must be done at all the locations that are necessary, for instance in the UI where the user directly interacts with the system. 

However, this is not a fixed rule and there are many reasons to do otherwise. In my experience it's the most discussed subject on projects and I try to be pracmatic and not religious. ADF applications are often very data driven, so we implement a lot of the business logic in the database and use them via AM interface methods (and a simple call to the database doesn't harm performance). But entity validations and JSF validators are also very much used. It's important to have experienced and open minded ADF, Java and database developers to discuss the best way to implement it.

And although Java developers are often a bit scared of using the database. It's often the database that lives the longest and survives multiple applications. So it seems only logic to use. 

Years ago, my colleague Lucas wrote an article about this subject, you can find it at http://technology.amis.nl/blog/759/role-of-the-database-in-a-j2ee-architecture-dumb-data-store-only-data-tier-also-business-tier

Ciao

  Aino

[Chris Muir]

Yes, I'm with Aino, a rigid adherence to MVC in all cases, which has
evolved anyway since it's original definition by Xerox PARC, will
cause problems, often besides the technical too. As an example of non
technical issues, we consider 2 important facts:

1) What's the skillset of the organisation? If they have a multitude
of PLSQL programmers to Java programmers, reusing PLSQL skills is
always going to be more cost effective.

2) Is there a large legacy PLSQL infrastructure - rewritting this from
scratch would be suicide for more projects

Also on the side, remember this is an "Oracle" related forum, and one
thing a lot of the Oracle people know is the database is the most
optimised locations for processing large amounts of data & many of the
associated business rules. I've heard a fair few stories now of how
midtier programmers have misinterpreted or misunderstood that
"simplisitic persistant store" and implemented a crazy Java solution
or two, with suprisingly bad results. Connor McDonald has the current
story of a Java programmer who came to him for assistance saying he
couldn't quite get something to work after a 1000 or so lines of Java,
something about joining rows from 2 tables in the database so he could
match records. Connor (in his infinite wisdom) introduced the Java
coder to the power of the "table join" in SQL queries, which takes
say, around 2 lines of code.

This is not to say a Java all solution wont work, but as per the first
point, a rigid adherence to a best practice across all scenerios
doesn't make sense in this case. As Tom Kyte likes to say, "One man's
best practice is another man's worst nightmare."

Cheers,

CM.

--
Chris Muir

Oracle ACE Director

[Romano Londt]

Hi,

I agree with Aino. In my experience the database will often overlive new front-end techniques.
Currently we are in a transition phase of moving from Forms to ADF. A lot of business-rules are already present in the database.
Therefore we created some logic to retrieve the messages from the database.

I think it is also depends on the team you are working with. When in transition to ADF you cannot expect developers to switch from coding database logic into coding java overnight.

Regards,

Romano

[Mitesh Gajjar]

Thank you all for your interesting comments and thoughtful discussion.
I appreciate it a lot.

In my opinion when developing large ERP type applications we do not
have the option of going with an either-or approach. It is not
possible to write all business logic in the database and use Model
layer for mainly transactional purposes. Scalability and AM
Passivation are some of the reasons.

I think it is natural for those with Forms background to evangelize
about a database-centric approach and those with Java background to
evangelize Middle tier approach (indeed there are strong logical
arguments by both sides). The answer as usual lies somewhere in the
middle. Let us think of ourselves not in terms of Forms/PLSQL or Java
community but as Fusion community.

I am neither for nor against keeping buss logic in the database or
Model layer but the reality is that it is not practical to write a
large application without having buss logic in both. A hybrid approach
seems to be the way to go where buss logic resides in database and
model depending on the task at hand.

There is a excellent and thought-provoking article by Grant Ronald
regarding Forms to Fusion migration with frank suggestions about the
correct approach and mindset to keep. It can be found at
http://www.oracle.com/technology/products/forms/pdf/10gR2/formsmigration.pdf.
I want to urge everyone to read it.

In our application as we continue adding logic to the AppModuleImpl
over time the code is becoming too fragmented and difficult to
maintain.

This is why I am interested in your opinions about suggested best
practices for organizing business logic in Model Layer as per the two
possible approaches I mentioned in my previous posts or your own new
ideas.

I would especially love to hear from Oracle PMs about how they
approach this in Oracle Apps and their thoughts on best practices.

Thanks,
Mitesh.

On Jan 31, 5:49 pm, Romano Londt <romano.lo...@gmail.com> wrote:
> Hi,
>

> I agree with Aino. In my experience the database will often overlive new
> front-end techniques.
> Currently we are in a transition phase of moving from Forms to ADF. A lot of
> business-rules are already present in the database.
> Therefore we created some logic to retrieve the messages from the database.
>
> I think it is also depends on the team you are working with. When in
> transition to ADF you cannot expect developers to switch from coding
> database logic into coding java overnight.
>
> Regards,
>
> Romano
>

> On Sun, Jan 31, 2010 at 11:00 PM, Aino <aino.andries...@gmail.com> wrote:
> > Yes, the never-ending discussion about where to put business logic :-).
>
> > I'm personally not so 'rigid' about the definition of the J2EE
> > architecture. The (logical) business tier (the model) may be implemented in
> > more than one technical locations and the database may be one of them.
> > One thing for sure is that often the data is the most important asset. So
> > we must make sure that we protect our data, make sure it's consistent and
> > that the correct business rules are applied to it. If possible, we should do
> > that as near to the data as possible: the database. In addition, it must be
> > done at all the locations that are necessary, for instance in the UI where
> > the user directly interacts with the system.
>
> > However, this is not a fixed rule and there are many reasons to do
> > otherwise. In my experience it's the most discussed subject on projects and
> > I try to be pracmatic and not religious. ADF applications are often very
> > data driven, so we implement a lot of the business logic in the database and
> > use them via AM interface methods (and a simple call to the database doesn't
> > harm performance). But entity validations and JSF validators are also very
> > much used. It's important to have experienced and open minded ADF, Java and
> > database developers to discuss the best way to implement it.
>
> > And although Java developers are often a bit scared of using the database.
> > It's often the database that lives the longest and survives multiple
> > applications. So it seems only logic to use.
>
> > Years ago, my colleague Lucas wrote an article about this subject, you can
> > find it at

> >http://technology.amis.nl/blog/759/role-of-the-database-in-a-j2ee-arc...
>
> > Ciao
> >   Aino

>
> > On Sun, Jan 31, 2010 at 6:06 AM, Trần Đức Minh <tducm...@gmail.com> wrote:
>
> >> Hi Jang Vijay Singh,
>

> >> *>>How much faster can you get than application server memory? *

> >> As my experiences, mostly come from my Forms skill, it help us avoid
> >> commonly mistakes when writing Java code accessing database such as using
> >> bind variables. It is best to find a way to let developer, without much
> >> knowledge in how database works, follow this best practice when develop
> >> database-backed applications.

> >> I totally disagree with your point: "*... database is just as a
> >> persistent store of data. *" since if we design our applications without

> >> aware of database capabilities, we might face the problems like:
> >> + hard to tune our applications for performance when problems come from
> >> bad design in database.
> >> + reinvent the wheel, I mean, we creates some stuffs to do the job without
> >> knowing that database can do it already.
>

> >> *>> **If clear MVC separation is maintained in your applications, you **
> >> shouldn't**  have to change your view layer every time business tier or
> >> model changes (unless** you mean you can change and redeploy your PL/SQL
> >> quicker than redeploying an application/business services? **I would seek
> >> the group's opinion on this one.) *
> >> *
> >> *

> >>> *>1. I'll try my best to put all the "business" inside

>
> >>> >the database where application can benefit from performance.

> >>> *
> >>> *
> >>> *

>
> >> How much faster can you get than application server memory? On the other
> >>> hand, the same logic in the database might add scalability issues (e.g. when
> >>> you create a mid-tier cluster to accommodate greater load, the database will
> >>> continue to be a bottleneck)
>
> >>> Business operations should need to hit the database for large data

> >>> access/writes *once in a while *(preferably behind the scenes, with
> >>> deferred writes - i am not sure of this specific function in ADFbc)*. *

>
> >>> Role of the database *now* (in the age of applications that are
> >>> middletier heavy), as I see it, is just as a persistent store of data.
>
> >>> Finally, as Michael Koniotiakis put it:

> >>>  *>You may feel like this way you split your business logic and you will
> >>> >not be able to find where you put what.*

>
> >>> Regarding Tran Duc Minh's point:

> >>> *> Implement solution this way, we will not have to change the View
> >>> layer*
> >>> *>whenever business changes.*
> >>> If clear MVC separation is maintained in your applications, you *
> >>> shouldn't*  have to change your view layer every time business tier or
> >>> model changes (unless* you mean you can change and redeploy your PL/SQL
> >>> quicker than redeploying an application/business services? *I would seek

> ...
>
> read more »