Where I put my business logic?

For example i create a simple JSP page with his DataAction. The JSP page contains a simple Input Form created with drag and drop from the Data Control Palette. The Submit button is also on the JSP page, now I want to insert the commit option without showing this to the user, like in 9.0.3 app.getTransaction().commit(); ...where I insert my source? Also if I want to insert source bevor i launch the JSP page, always using DataAction (without using BasicADFAction from Steve Muench), where can I do this? The execute method in DataAction is final!

One way to acheive auto commit is with Data Action chaining.
For ex:- You could have pageflow like:
createEmpDA ---> /createEmp.jsp
createEmpDA DataAction would create an empty row.
and forward to createEmp.jsp which will show an input form with a submit button.
Now wire the submit button as follows.
createEmpDA ---> /createEmp.jsp ---> commitEmpDA
Change the submit action in createEmp.jsp to commitEmpDA.
In StrutsPageFlow.
Drag-n-drop commit operation from DataControl palette onto commitEmpDA DataAction.
This would commit the transaction.
Page flow could end up to browseEmp JSP page which shows all the employees including the newly created one.
createEmpDA ---> /createEmp.jsp ---> commitEmpDA --> browseEmpDA ---> /browseEmp.jsp
raghu
JDev Team

Similar Messages

Where do I write business Logic?

Hi,
Where do I write bisiness Logic?
Tutorial said "It is common practice to include the bean property and the Action
implementation to which it refers within the same bean class".
But I thought EventHander Impl is better to write business Logic
like retrieving the data from database.
Which is common use?
Or I need to choose them depending on the situation?
Thanks in advance for you help.
tomo

Thanks for the reply!!
But I am still confused.
I thought I can write business logic A and B.
What is difference between A and B ??
Hi tomo,
In the two options you provide the difference is not that much. The ActionListener instance willhave to be registered in your JSP of course to listen to the button or hyperlink with the f:action_listner tag. But in both cases your biz logic is in your ui. I think that is the wrong direction for you to head.
I think the real question should be (forgive me if I'm pulling the discussion away from your question, but I think this is relevant) where does the business logic go.
As Kito said your biz logic belongs apart from your UI logic (classic MVC approach). So in the real world what does that mean? As you suggest in option B in your last post a bean provides an action so that it can be specified via the actionRef attribute. This action in turn invokes a method on the bean it comes from which then invokes the business logic on the 'real' business logic.
The Action becomes simply a translator (or part of the Adaptor pattern from the GoF book).
For example lets say you have a bean that does biz processing like this;
public interface CatalogFacade {
public Collection getProducts(ProductSearchCriteria criteria);
}And you want to invoke that 'business logic' from your JSF UI. The button would be declared with this code
<h:comman_button id="searchCommand" type="submit"
                    label="Search"
                    commandName="search"
                    actionRef="searchBean.searchAction"/>In your searchBean you have many options to return the searchAction but I prefer the following
public class SearchBean {
   public SearchFacade searchFacade = null; // this could be a managed bean or an EJBSession or whatnot
   public ProductSearchCriteria productSearchCriteria = null; // this should be 'filled' in by the form the button is on
   private transient Action searchAction = new Action() {
    public String invoke() {
      return search();
public Action getSearchAction() {
    return searchAction;
public void search() {
    Collection products = searchFacade.search(productSearchCriteria);
    // place the products collection into the next page's bean so that is can be found via valueRef attributes
}Notice that no database hits are happening in the UI code. Also there is no business logic here either.
It is very important to keep these two concerns divided for ease of maintenance. The typical reasoning goes something like this, 'your ui is very likely to change so keep it separate from your business logic'. Other reasons to be careful about mixing UI and biz logic is the likely hood that you will get very different behavior (one probably wrong) if you have to and another client to your biz logic.
For example in the earlier product search stuff. If we needed a web service front end to the 'searchProducts' functionality and we had the db hit happening in the action or page bean we would be stuck. With the above impl we get to just put a WS over the facade and we are done.
Hope this helps.
You can also look at some of the blueprint patterns for more info. They start here;
http://java.sun.com/blueprints/patterns/index.html
While some of the EJB specific patterns might be more involved than you need they provide excelent archtectural guidence for web only apps as well.
Good luck,
-bd-

Where to implement my Business Logic in ADF?

Hi,
I am new to Oracle ADF. I found this forum very useful to get my queries and doubts answered. Thanks to the participants.
I am basically from Struts background,
Where i design my UI in jsp pages using Struts tags,
Actions and some utility classes handles my most of the business logic (generally called as Business Layer)
Then i have custom DAOs or Data Layer to query or update the data in database.
Now as I am into new Project and I have to learn Oracle ADF.
I started learning this by following some questions in the forums and various sites (from Google).
I got info on How to create Entity Objects, Value objects etc.
But my major doubt is where shall i write my Business Logic in this stack?
I can easily drag and drop my data controls into my JSF page and create table, forms or charts. But if i have a multi line business logic, say for a Submit button, In which i may be doing the following steps -
a. Get data pertaining to user role , department, his tenure in the department etc
b. On submit do processing based on data collected in above step.
c. update data in data base.
d. initiate an approval process
e. call some business process for Approval
f. Audit Trail
g. Transaction handling
and so many other steps (I know most of you will have gone through these situation before starting work on ADF)
Now, in the above scenario in Oracle ADF layers where shall i write this whole bunch of logic or steps and then forward the user the page depending upon the outcome of this logic.
Please let me know where to write all this??
Thanks a lot,
Amit
Edited by: ur.amit on May 13, 2010 4:58 PM

Generally speaking all of that code would reside in the app module Impl classes or the View object Impl classes - for VOs and AMs you can expose subclasses and add code in there - you can then define whether any of your methods should be exposed to the client, in which case they appear in the Data Controls panel as operations.
General word of advice -keep business logic code in the Model - don't be tempted to start trying to access your AMs and do any of this stuff from the ViewController project. Keep it nice and simple and just access ALL the business logic code through ADF Model.
Hope this helps
Grant

Where to put the logic!

Hello everybody!
I have a big doubt and so does my CIO.
I'd like to develop Web Services using the facade pattern (Entity + Session). I prefer to put the business logic into the stateless EJB and just go to the database to insert, update or delete records.
But the boss says it would be better just to develop a pl SQL (Oracle) that has all the business logic into it and just make the call from the Stateless.
Is there a general approach? What do you recommend?
Thank you very much!

Hi,
in my experience it is better to put the logic in the bean itself.Because if we want to change the database later, it would be very easier.

ADF11g: business logic in ADF BC or PLSQL?

Hi All,
For a new development in ADF 11g , where we should put our business logic: In ADF BC or in PLSQL?
What if we write all the bussiness logic in plsql? Because if tomorrow ADF goes(which I know is not ging to happen soon), we can expose pl/sql as web services, and new UI technology can use it. And we will not struggle on migration, as we are struggling today from Forms to ADF.That's what my manager says......
Though I know that we can write our business logic in ADF BC, and that too can be exposed as web service.
But I still need more suggestion on this, which one is better to write bussiness logic.
Thanks
Vikram

We have a team with mixed skill sets, so consequently some of our business logic is in ADF/BC and some is in PL/SQL.
Having some in PL/SQL allows my project manager to divide and conquer the work to be done on an adf project easier than I can train the pl/sql guy to be an adf guy...supposedly.
Also our project manager is also a techy with a primarily pl/sql orientation.
I like Java better because it is new and fun for me, but that is not much of a reason.
I have been to many presentation's of Paul Dorsey's BRIM product. Paul is absolutely certain that you and your manager are doing good when you put business logic in the database. Paul goes even further. I respect him and his arguments are sound.
I still like Java better...mostly because I have done pl/sql for ages and am tired of it. :-)

Different business logic

Hi Friends
I have installed 0CML_DELTA extractions from business content and in my testing i found that for amount field the program logic is different than my business logic.That's why the amount field is not reflecting in BW with same amount.
What sould i do to correct?
Your reply would be appreciated with points.
Regards,
Chama.

if the only problem is your amount, you can use a user-exit to overwrite the standard amount with the value that you want (with your own logic)
if there are other issues, you are better off creating a new generic extractor with the same structure and put your business logic in a FM to pass data to BW

Where to put logic with Transfer Objects?

I'm playing with Transfer Objects for the first time, and have got this one class I'm not sure how to design the Transfer Object for. The problem is that I have some logic that is needed by both the domain model and by the client.
The class is named Moment. It's basically a wrapper around the java.util.Calendar class because I don't like passing objects of that type around in my code. That Calendar class is just to complicated to expose everywhere.
So, an easy example is that internally, Moment stores time in millitary time. I need a method that will take an hour, a minute, and AM or PM and convert it to millitary time for storing internally in the Moment.
Before Transfer Objects, this was easy enough of a decision. Moment had several factory methods called makeMoment. One of these took three arguments: hour, minute, and AM or PM. And, it internally converted to millitary time and stored the time in the Moment. However, now that the client is operating on Transfer Objects and not Domain Objects, if I put that method on Moment in the domain model, it won't be available to the client. If the client takes user input in AM/PM format from the user, it would have to duplicate logic already implemented in the model.
Options I think I have:
1.) Put the conversion method in MomentTO, maybe make it static. Then, my Moment class calls this method on MomentTO to do the coversion. This would work, but it seems funny to have the domain model calling business logic inside the Transfer objects.
A variation of this solution is just whenever my domain model wants to create a Moment, have it first create a MomentTO via a factory method that could do the coversion, and pass the MomentTO to a Moment constructor. This seems even funnier though to have the domain model creating Transfer Objects for internal use. It just seems to me that the point of Transfer Objects is to export information about the domain model to the client, leaving a lot of the specifics behind. Not something that the domain model uses for processing internally.
I could put the conversion method on the MomentTO and just say anybody who wants to create a Moment using anything but millitary time is going to come from the client that will be using Transfer Objects. Nobody else will be creating moments using anything but straight millitary time. But, this approach seems inflexible.
2.) Make a separate library / package that is available to both the domain model and the client. The inital reason I don't like this solution include the fact that I don't need much more other logic to be shared like this, so this package would be really, really small.
Any suggestions? Just can't seem to find something that makes good sense. I do have several other things like this for this Moment class in creating a Transfer Object for it. But, it is just this one class that I'm having this problem with.

>>
If this is for the pursuit of knowledge, then thatis
all well and good. However, if you actually wantto
do something with this application, I wouldrecommend
the following link:
http://xp.c2.com/YouArentGonnaNeedIt.html
- SaishI think you missed the part in the thread where I'm
not seeing the evil of Transfer Objects. Please
explain. They really don't seem that much work to
develop to me.
Fair enough. However, my point is that any time you develop something that 'might' be needed is time you are taking away from time developing things that 'are' needed.
One of the listed advantages of the Transfer Object
pattern in the Core J2EE Patterns is hiding
complexities of the domain model from the client.
This seems to be very handy for my application.The session facade pattern would accomplish the same effect.
. Many of the domain model objects are versioned,
but the first three iterations of development that I
want to complete before deployment need to know
nothing about the versions. With transfer objects,
this can all be safely hidden in the Application
Service objects.
I fail to see how transfer objects themselves would not require versioning or modification. Given a large enough transfer in the domain model, it woud be difficult to insulate an associated transfer object. Granted, these changes may occur less frequently.
Plus, I'm trying to figure out how the hell Commons
Validator works with Spring. Really wish I could
find a getting started guide. What I've found so far
makes it look like it's going to be easier to
validate Transfer objects than my domain model
objects, because all the validated fields will be on
one object. Not mostly on one object with some
fields scattered about like they would be with domain
model objects...I've found good FAQ and HOW-TO documentation at Jakarta while working on several Commons projects, including Log4J and FileUpload. Validator has no such online documentation?
For Spring, I recommend the new Johnson "J2EE Development with Spring" and (I forget the author) "Spring in Action".
- Saish

Where is the best place to implement business logic in ADF application?

I am using jdeveloper 11g R2 , JSF Facelet
Where is the best place to implement business logic in ADF application?
I mean something like service layer in Spring
Appreciate your comments
Regards
Mohsen

Depends on what your logic does and what data it deals with, but in general business logic is in the ADF BC layer.
Some goes into entity objects - for things like attribute or row validation.
Some goes into view objects - for things like calculation.
Some goes into AM - for things like service methods for UI clients.

BPEL Process with complex Business logic

Hi,
So far my knowledge,complex business logic can be implemented by different way in bpel process.
1. Business rule
2. ejb with java callout
3.ADF BC as servcie
Can anybody please suggest which approach do I need to follow,what are the pros and cons of each one,and best practices to use when and where?
Thanx in advance.-Aswini

Hi
In addition to what Naresh already mentioned, you can consider these points also.
1. If your process is complex, see if some part of the process can be common across and it can run by itself. Then you can use SubProcess concepts also. Say for example, if process involves credit card processing, it can be in a sub-process and you can call it in the main process. Like that any common approval flows can be put in a separate sub-process.
2. I would discourage using Java invocations if possible as they have some limitations and you can use reasonable amout of code in invoking java code within the bpel process. If you have lots of validations to do on a bpel process, you can consider using CallBackHandlers and do the validation on a task assignment, submission or any task action in general.
3. Business Rules can be used to control the actual flow of the process itself. Based on busiiness rule, you can decide if a set of tasks needs to be included or not in the approval flow. This is in addtion to the actual data that controls the business rules, that can be changed dynamically without the code change to core bpel process.
Which version of SOA are you using or plan to use. I would recommend the latest version SOA 11.5 + Feature Pack applied.

Where to put EJB design patterns?

Im considering where to put the EJB design pattern classes and files.
i.e. Facade, Data Access Objects, Transfer Objects, Delegate...
I was thinking since the EJB business logics and implementation should be hidden from the user, then it is more logical to place these classes at the webapp.war inside of the ejb.jar.
What are your thoughts guys?

Photoshop patterns and normally stored in sets the set files have an extension of .pat. You may also add individual patterns using menu Edit>Define Pattern. In some Photoshop Pattern dialog you will see a little gear icon to open a Fly-Out menu in that menu there is a entry for Photoshop Preset Manager. The are also other ways to get into the Preset manager. In the preset manager you can manage many types of presets. Using its pull-down menu select patterns. You can Load an save patterns sets. To save a set tou heed to hilifht the paterns yoy want to include in the set. You can also delete and rename patterns.

Where to put java code - Best Practice

Hello. I am working with the Jdeveloper 11.2.2. I am trying to figure out the best practice for where to put code. After reviewing http://docs.oracle.com/cd/E26098_01/web.1112/e16182.pdf it seemed like the application module was the preferred spot (although many of the examples in the pdf are in main methods). After coding a while though, I noticed that there were quite a few libraries imported, and wondered whether this would impact performance.
I reviewed postings on the forum, especially Re: Access service method (client interface) programmatically . This link mentions accessing code from a backing bean -- and the gist of the recommendations seems to be to use the data control to drag it to the JSF, or use the bindings to access code.
My interest lies in where to put java code in the first place; In the View Object, Entity Object, and Am object, backing bean.....other?
I can outline several best guesses about where to put code and the pros and cons:
1. In the application module
Pros: Centralized location for code makes development and support more simple as there are not multiple access points. Much like a data control centralizes services, the application module can act as a conduit for different pieces of code you have in objects in your model.
Cons: Everything in one place means the application module becomes bloated. I am not sure how memory works in java -- if the app module has tons of different libraries are they all called when even a simple query re-execute method is called? Memory hog?
2. Write code in the objects it affects. If you are writing code that accesses a view object, write it in a view object. Then make it visible to the client.
pros: The code is accessed via fewer conduits (for example, I would expect that if you call the application module from a JSF backing bean, then the application module calls the view object, you have three different pieces of code --
conts: The code gets spread out, harder to locate etc.
I would greatly appreciate your thoughts on the matter.
Regards,
Stuart
Edited by: Stuart Fleming on May 20, 2012 5:25 AM
Edited by: Stuart Fleming on May 20, 2012 5:27 AM

First point here is when you say "where to put the java code" and you're referring to ADF BC, the point is you put "business logic java code" in the ADF Business Components. It's fine of course to have Java code in the ViewController layer that deals with the UI layer. Just don't put business logic in the UI layer, and don't put UI logic in the model layer. In your 2 examples you seem to be considering the ADF BC layer only, so I'll assume you mean business logic java code only.
Meanwhile I'm not keen on the term best practice as people follow best practices without thinking, typically best practices come with conditions and people forget to apply them. Luckily you're not doing that here as you've thought through the pros and cons of each (nice work).
Anyway, back on topic and off my soap box, as for where to put your code, my thoughts:
1) If you only have 1 or 2 methods put it in the AppModuleImpl
2) If you have hundreds of methods, or there's a chance #1 above will morph into #2, split the code up between the AppModuleImpl, ViewImpl and ViewRowImpls. Why? Because your AM will become overloaded with hundreds of methods making it unreadable. Instead put the code where it should logically go. Methods that work on a specific VO row go into the associated ViewRowImpl, methods that work across rows in a VO go into the ViewImpl, and methods that work across VOs in the associated AppModuleImpl.
To be honest which you ever option you choose, one thing I do recommend as a best practice is be consistent and document the standard so your other programmers know.
Btw there isn't an issue about loading lots of libraries/imports into a class, it has no runtime cost. However if your methods require lots of class variables, then yes this will have a memory cost.
On a side note if you're interested in more ideas around how to build ADF apps correctly think about joining the "ADF EMG", a free online forum which discusses ADF architecture, best practices (cough), deployment architectures and more.
Regards,
CM.

Where to put Validation Code?

Up until now, Im still having second-thoughts of where to put validation code when setting attributes of an entity.
Right now I have created lots of custom validators --(implement JbovalidatorInterface) that calls stored procedures to validate the value entered. But sometimes, i just use a ViewObject and query it on the setterAttribute method of the Entity and just manually throw a JboException of the value is invalid based on some business rule.
Question is, what are the best practices where to put validation codes? do we have to be strict that we always put all validations on Validators or are we free to just throw JboExceptions anywhere on the BC classes' code.
regards,
Anton

1. The reason I have a custom validator and I don't normally use the built in declarative validators is that the error message generated when the validation fails is fixed, only one message. I decided to have create a custom validator is that I need to test a one attribute for many cases in each case should produce a distinct error message. So if I use the built in validators, I would have to create lots of built in validators for that single attribute only. (and i have lots of entities and lots of attributes that needs business rule validation). So, I decided to create a custom validator, that calls the stored procedure, the stored procedure takes care of all test cases, for that attribute only, and I can return a dynamic error message depending on the test case that failed. What do you think about the approach?
It's a little extra work to create a reusable validator class that will only be used once, but whether you do it that way or encapsulate the call in a helper class that your one-off method validator code delegates too, it seems similar to me. So it's more of a stylistic choice for you which you like better. Now, if your reusable validator were enable to encapsulate
2. When I said anywhere; I meant inside the setterAttribute methods on the Entity and on the ViewRowImpl, orThe ViewImpl class or inside a method on an ApplicationModule?
Rather than writing code in the setAttribute, I recommend using attribute-level method validators. This makes it more clear where all your validation code lives.
I don't recommend performing validation in the view object level since entity objects are the component in the system that are tasked with handling validation. It would be easy to circumvent view level validation checks unless you make a lot of assumptions about exactly how your application is working.
3. One other issue is that Validator methods are for validation purposes only. So its not a good idea to put in attribute setters to other attributes inside there. So you put the attribute setter logic outside of the validator usually inside the setAttribute() just after validator returns. But there are cases that is very straightfoward to put validation logic inside the setAttribute; meaning, inside the setAttribute() method, I test for a condition, if it fails, just throw a JboException, if its true, continue with the otherAttributes setter logic.
Whether attribute setting of other attributes is performed in a setter method or in an attribute-level method validator, either way you will need conditional logic to avoid going into a validation "loop" (which eventually will throw an exception if after 10 attempts the object is still not valid at posting time.

BC4J - Big Project - Business Logic

What is the suggested best practice on where to locate business logic in a big application?
It would appear that entity objects are good for table/domain level validation.
View objects are good to ensure that the data between multiple tables is copesthetic.
But where would one place business process logic that could potentially span multiple views and even multiple application modules?
Also what is the difference between retrieving an application module using the ApplicationModuleHome.create function and from the applicationpool?
Thanks,
Marty
null

re: "duplicate"
You betchya. This is mimicing a SmallTalk implementation I worked with years back.
In some cases, the checks are not duplicated because they share "objects" instantiated for those entities. And in the case of 3 frames all with the same field.. only one check fires ( the active frame where they entered the data ) and all the others don't fire.. they just clean up when the user corrects the data.
In some cases putting validation in the EO appears to just add work at both ends, and adds another layer of confusion for programmers. ( I.E. A programmer is looking at the code.. it is NOT apparent without complete knowledge of the EO code what is and is not being checked. Is that maintainable? maybe, maybe not )
Here's an example of an edit check... confirming that a part number is valid for a custom Find Panel.. and while we're at it, let's turn * to % for a LIKE statement so all our Access users don't get confused:
String oldPart = ((ImmediateAccess)partNumber_tf.getDataItem()).getValueAsString().toUpperCase();
String wildPart = new String();
if (oldPart.indexOf("*") > 0)
{ wildPart = oldPart.substring(0,oldPart.indexOf("*"))+"%"+
oldPart.substring(oldPart.indexOf("*")+1);
oldPart = wildPart;
try { ((ImmediateAccess)partNumber_tf.getDataItem()).setValue(oldPart); }
catch ( Exception e0 ) { System.out.println(e0.toString()); }
if (oldPart.indexOf("%") < 0)
if (!isValidPartNumber(oldPart) )
try { ((ImmediateAccess)partNumber_tf.getDataItem()).setValue(""); }
catch (Exception e0) { System.out.println(e0.toString()); }
boolean isValidPartNumber( String partNumber )
boolean isValid = true;
if (!partNumber.equals("") )
try
Statement call= OpenDBConnections.myJdbcConnection.createStatement();
ResultSet rset=call.executeQuery("SELECT getPartDescription('"+
partNumber+
"') AS PART_DESC FROM DUAL");
rset.next();
if (rset.getString("PART_DESC").startsWith("ERROR") )
statusLine_tf.setText("USER ERROR: Invalid Part Number!");
Toolkit.getDefaultToolkit().beep();
isValid = false;
else
{ status_tf.setText(""); }
rset.close();
call.close();
catch (SQLException esql)
{System.out.println(esql.toString());}
return isValid;
Notes:
1. I do a JDBC call cuz I don't want a lock on my target records. It's a bloody read only request. ( Or is there a way to set that up..as far as I can tell UPDATABLE seems to affect the UI when defined in the View Object.. it has nothing to do with locking? The EO may be updatable by the application... by read only for this particular purpose... )
2. If I understand you right, you are saying to do the IsValidPartNumber code in the validateEntity() method. I want it NOW.. not at commit time.. or is validateEntity "run" on any change to the EO? Or should it be put on the impl setr so that the try catch around the setValue() of the DACF element will catch it? ( I like that )
3. The status line and beeping is managed by the try catch around the dacf setValue(), as well as the clearning of the appropriate DACF control and refocus (if needed ).
4. And that the validation should REALLY be applied to a DOMAIN of "PartNumberDomain".. since it really applies to many EOs with attributes that are of domain "PartNumberDomain".
That last item is VERY interesting to me. I used such stuff in Rdb in the database. Catch is that domain and their power and implementation is scantily described in training and in the online Help.
I'm guessing that when I do a DACF entry that the setr in the EO can be used to validate.. and that the DOMAIN edit gets automatically executed as well.. and that it shows up as a JBOException to the try/catch at the application source level for the programmer to deal with, right?
Note that when Dec/Rdb started on this sorta course 10 years ago, it was clear to everyone that it was a house of ravioli code.. and that without a POWERFUL object repository it was very, very difficult for la rge projects to be built so that programmers would have clear visibility to all the conditions/issues.
Want to bet that you can count on one hand (or less) the number of customers outside of Oracle who have implemented domain validation code and applied it to Entity Object attributes?
Note that in all these cases, I still need to implement the same checks in my triggers to protect the database against ALL comers. So everything gets checked twice.
re: BC4J, wrappers, and java stored procedures. All interesting ideas. I booted that option out during this implementation because the goal was to implement the application... I estimated we'd extend the project another 2-3 months by taking the approach you imply, due to learning curve, conceptual errors on our part during implementation, bugs in the Oracle code awaiting fixing, ad nauseam. That rough estimate has been born out by the fact that JDEV issues of implementation has caused my project to slide over 2 months. Simple, easy things I had alotted a short effort for based on experience with MS Access, Delphi, Forms and other tools turned out to wildly off base. ( Example: the imageControl that simply doesn't work, but is documented as being so easy and quick to put in ).
Thanks again. BTW. If you don't know, I'll be at Oracle HQ on Friday the 16th. Hope to see you again, if just to say hi.
null

Model Object / Business Logic question

Hello,
Question about how to architect the model objects and services in our system. We are defining our own Model Object / Transfer Objects without the use of an ORM tool (long story). Some of these model objects have to maintain Association objects such as:
public class Teacher {
     private List<StudentAssociation> kids;
public class StudentAssociation {
     private Teacher teacher;
     private Student student;
     private Date fromDate;
     private Date toDate;
     // Getters / Setters ....
}My question is, where should the logic be to add, remove student associations? Originally we had it defined in the Teacher model object with:
public void addStudentAssociation(Student student, Date fromDate, Date toDate);
public void removeStudentAssociation(Student student, Date fromDate, Date toDate);But I am hesitant to put such logic in the Model Object. I always thought those should be pretty empty of any sort of business logic. Instead I want to have a TeacherService that does that and instead just a getter/setter on the Teacher object for the Association List. However, in doing that, I find I have to create a new List of Associations then call the setAssociations method on the Teacher object, which seems kind of strange.
Is it bad to put the add/remove method in the model object itself? The remove logic has a bit of business logic in it, so it seems weird being there.

Not sure I can be of much help, but here's my two cents worth:
You have a teacher object and student object. A teacher doesnt really have an association with a student. I think you need another object such as a class object. I class has a teacher and the students (an association can be a business association, social association, etc). That same teacher may be assigned to other classes (provided they dont occur at the same time since the teacher cant be in the two classes at the same time. Likewise, for a student. Complicating things is the fact that a teacher of one class may be a student in another class. Also, a class may exist that has students but no assigned teacher yet (your original idea wouldn't be able to handle this since you will need a teacher before you add students). Another case, you have a class without students. Still another case, you have people (either future students, or teaching staff that haven't been assigned as teachers yet), but no classes yet., I think it would be best to figure out a database schema first (you can use Oracle Lite, MySql, etc).
here is an example:
Assuming you are putting this in a database I would create tables and fields something like this:
Person ((a person is either a student or teacher, or just someone that is no longer a student or teacher but may be one day))
personId not null
firstname not null
middleName nullable
lastname not null
ssn not null
Class ( a class is where a teacher teaches students))
classId not null
nameOfCourse not null
building nullable (may not be assigned yet)
room nullable (may not be assigned yet)
startDate ((when the class starts)) nullable
endDate ((when the class ends)) nullable
teacherId ((this is the parentId from the person table)) nullable
Students
personId ((this is the personId from the person table))
classId
associations:
a class has 0 or 1 teacher,
0 or many students
a teacherId must exist in the person table as a personId
a studentId must exist in the person table as a personId
(if you delete a personId in the person table, it cascades deletes any teacherId or studentId of the same value)
your class has a collection of students. therefore:
private List<Student> students
Your class will also have something like
addStudent(Student student) (throw exception if student already exists) (note you dont pass in the start and
end date since its the class's responsibility for start and end date, not student)
isStudent(Student student) (return true if student is already in class, false if not)
deleteStudent(Student student) ((returns true if student found and deleted, false if student not found to delete)
Your business logic can check things such as if the start date occurs before the end date (an error), you have a class with no teacher or no students, etc. The first case you can do in the database with constraints if you want, but the second you cant since you want to store info for a class even if a teacher isn't assigned to it yet.
One way to do this is to have a validate() function in your class object. The validate() function checks such things as a class with no teacher and returns a collection of warnings if it finds anything wrong. All the above is just something off the top of my head. So there may be some issues with my approach that you will have to work out.
Good Luck!

Design ?: how much business logic in JSP?

Hello everyone --
I can't seem to make up my mind and my collegues aren't helping, so maybe a few of you could offer your opinions.
I have a simple JSP that is just a web interface to a database and right now I have the business logic (an entire class called TalkToDb) completely separated from the JSP in another file. The JSP isn't really THAT dynamic (I don't even have links); the top part is just a series of forms that query and update the db. It's the bottom part that has dynamically-generated tables populated by db info.
The question is, does the business logic really need to be separated from the presention stuff? Is it really dumb integrate my TalkToDb class into the JSP? What are arguments for doing it one way over the other? Thanks a heap for any feedback at all,
-Kwj.

For a simple, one page project, you don't gain much in speed and development time by separating the logic, but it's a bad habit to get into if your goal is to develop sophisticated web applications. The rule I develop with is "if they tell me they want one page, anticipate them wanting ten pages". You never know where a "simple" app will grow. Using a class to handle your logic is a better design.
If you are confident that the project is going to be a quick, cut and dry database query and results display, then you can put it all in the JSP page, but just know that you are decreasing scalability for the tradeoff of quicker development.
No one will tell you that you did it wrong if you use a class and a JSP page together. However, you open yourself up to criticism from people looking for more sophisticated designs if you throw it all in the one page.
Now, that all being said - I have a few single page JSP's that we didn't want to create entire apps for. We just put the whole report logic right on the page. But the majority of my projects are well designed MVC applications.
Michael

Where I put my business logic?

Similar Messages

Maybe you are looking for