Transfer Object Pattern and Concurrency Transaction Mgmt

I am developing an application that implements a remote rich client. For
performance reasons I have chosen to use the Transfer Object pattern. I
have been very successful with this from a performance standpoint, it
really paid off. I am using it in combination with an assembler pattern
to construct Transfer Objects for the view and to also reassemble domain
objects based on changes made to transfer objects on my client side.
Anyways the only problem I am having with it is I can't seem to figure
out how I should implement optimistic locking with it. Is there a best
practices to handle transaction control here?
I generally try to keep visibility of stale data down, but there are still
situations where concurrent clients could have requested to edit the same
the Transfer Object at the same time. I would ideally like to handle this
using a flavor of optimistic locking. I in fact have implemented
optimistic locking on the domain side, but now I am not sure how or if I
should integrate this into the Transfer Object or View side. The version
field used in optimistic locking is generally a hidden field. The only
way I can see to handle this with the view side is to expose this field on
the Domain Objects and actually store it into assembeled transfer objects.
This seems like it may be a bad idea from a design standpoint.
The problem is the client requests data and it assembled and delivered to the client. Then at some later time the client may send a request to the server to update this data. At this time a new transaction must be started where the server reloads the domain data and copies over the requested changes. Since the domain data was just loaded you wouldn't ever trigger a versioning problem unless the version was maintained on the transfer object and copied over as well. I am developing this project with hibernate on the back end and unfortunately hibernate doesn't acknowledge manual changes to the version field.
I just feel like there must be a better way to do this. I believe that using the Transfer Object or DTO pattern for remote client/server architectures is pretty common. So there must be a best practice to deal with concurrency? Suggestions, insight, lay it on me please.
thx

I personal respect both concepts and am using both in an application I am currently work.
Firstly, I have my Transfer Object which I call xxxData.
Next, the entities are called xxx
I have my DAO classes that handles all CRUD operation. but within the DAO class I have two methods
private <EntityClass> retrieveEntityFromObject(<EntityClassData> data) {}
private <EntityClassData> retrieveEntityFromObject(<EntityClass> entity) {}so with these methods, I separate my business logic from my data layer. My codes will alway use data objects instead of entities. For example, a create method will be
public ProductData createProduct(ProductData data)
entity.persist(retrieveEntityFromObject(data));
}I hope someone understands
Regards

Similar Messages

Transfer Object pattern question

Hi, developers!
I created a Transfer Object pattern class, that has an array field. See below:
class TOClass {
private int[] values;
//notice that I am using clone() method
public int[] getValues() {
return (int[])values.clone();
public void setValues(int[] values) {
this.values = (int[])values.clone();
}Would you do like I did?
Thanks in advance!

Thank you, you all!
I am testing the solution you presented, Saish, and I am verifying yet. But I see that the problem of manipulation of data continues, like dubway said. But, this discussion gave me a lot of ideas! (I didn�t know Collections.unmodifiableList() method yet, very interesting method). I will continue my researchs for the best solution.
But I have to worry only when the getter method is used, because I don�t know what other developers will do with the value returned. I don�t need to worry about setter, because the only person that sets is me, and nobody else.
And one more thing. My TO class does not contain only one field. There are other fields: Strings, BigDecimals, etc, but these other fields are easy, I just have to create getters and setters for them. There is only one field that has the "behaviour of an array". But because of the fact that there are other fields, to not make this class complicated and "dirty" visually, I really want to use simple getters and setters methods, only. Your solution is not providing getters and setters exactly, Saish. I want to follow the Transfer Object pattern, whose feature is the existence of getters and setters, only.

Adobe Flex + PHP (Using Data Transfer Object pattern in amf)

hello
i'am using amf to connect my flex application to the php back end,but i want to use DTO(DataTransferObject), i haven't enough info about this pattern.
can you introduce me a reference or have you any suggestion?
thanks for your attention
Uniqe_max (amin shahnazary)

here is another way of doing it
http://www.youtube.com/watch?v=1n1uHQAP18Q
http://www.youtube.com/watch?v=fQsCBk9tvkQ

How to combine Session Facade and Transfer object?

Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
Thank you!
Astghik

Astghik wrote:
Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
I would simply recommend establishing a service tier. Your services should be stateless. You can go the extra mile and have a session facade, but in the majority of cases, coding to an interface for your service accomplishes the same goals.
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
The idea of the transfer object is very similar to the Command pattern. I think if you investigate that pattern, it will be more obvious. The transfer object reduces network latency by consolidating all the parameters into an object, ideally, this also consolidates multiple method calls. If you combine a transfer object (or command object) with a service tier, you get the best of both worlds. The service can delegate calls to helper objects (or other services or components) using the data in the transfer / command object.
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
The is your domain. It will vary from application to application. The principles above are more general (e.g., patterns and architectural tiers) and should apply to most domains. However, your actual use case may require something different.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Consider using something like iBatis or Spring's JDBC templating to make your life easier with JDBC.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
Versioning is a separate issue. Generally, the more coarsely grained your transfer / command object is, the more changes are likely to impact dependent objects.
Your command or transfer object does not have to be a vanilla JavaBean, where you are basically creating a bean that has data from other objects. You can simply use your command / transfer object to encapsulate already existing domain objects. I see no need to map to a JavaBean with what you have described.
Generally, a method signature should be understandable. This means that many times it is better to pass the method, say, two coarsely grained objects than a signature with a dozen primitives. There are no hard and fast rules here. If you find a method signature getting large, consider a transfer / command object. If you want one service to delegate calls to a number of other services, you can also create a transfer / command object to furnish the controlling service with the data it needs to invoke the dependent services.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
This is a large, open-ended question. If you are going to display it to a user on a screen, I do not see how you avoid a network transfer with the data. The general answer is to not pass the data itself but rather a token (such as a primary key, or a primary key and a start and stop range such as you see on a Google search result). You do want to limit the data over the network, but this comes at a cost. Usually, the database will receive additional load. Once that becomes unacceptable, you might start putting things into session. Then you worry about memory concerns, etc. There is no silver bullet to the problem. It depends on what issues you are trying to address and what trade-offs are acceptable in your environment.
Thank you!
AstghikBest of luck.
- Saish

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

Data access object pattern

Hello,
I am trying to implement the Data Access Object pattern and I have the following bean:
package com.netpepper.ecards;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.faces.application.Action;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
* @author Julien Martin
* Card class: represents the card sent from a member of the public (the sender)
* to another member of the public (the recipient).
public class Card {
 private static Log log = LogFactory.getLog(Card.class);
 private long id;
 private String from_email;
 private String to_email;
 private String image;
 private String bgcolor;
 private String font;
 private String from_name;
 private String to_name;
 private String message;
 private String title;
 private boolean received;
 private boolean sent;
 private String send_date;
 private String response;
 * Public empty no-arg constructor
 public Card() {}
 * Full-fledged constructor
 public Card(
 long id,
 String from_email,
 String to_email,
 String image,
 String bgcolor,
 String font,
 String from_name,
 String to_name,
 String message,
 String title,
 boolean received,
 boolean sent,
 String send_date) {
 setId(id);
 setFrom_email(from_email);
 setTo_email(to_email);
 setImage(image);
 setBgcolor(bgcolor);
 setFont(font);
 setFrom_name(from_name);
 setTo_name(to_name);
 setMessage(message);
 setTitle(title);
 setReceived(received);
 setSent(sent);
 setSend_date(send_date);
 * @return the background color choosed by the sender.
 public String getBgcolor() {
 return bgcolor;
 * @return the font choosed by the sender.
 public String getFont() {
 return font;
 * @return the sender's email.
 public String getFrom_email() {
 return from_email;
 * @return the sender's name.
 public String getFrom_name() {
 return from_name;
 * @return the card's id.
 public long getId() {
 return id;
 * @return the image choosed by the sender.
 public String getImage() {
 return image;
 * @return the message input by the sender.
 public String getMessage() {
 return message;
 * @return <code>true</code> if the card has been received, <code>false</code> otherwise.
 public boolean isReceived() {
 return received;
 * @return <code>true</code> if the card has been sent, <code>false</code> otherwise.
 public boolean isSent() {
 return sent;
 * @return the title choosed by the sender.
 public String getTitle() {
 return title;
 * @return the recipient's email.
 public String getTo_email() {
 return to_email;
 * @return the recipient's name.
 public String getTo_name() {
 return to_name;
 * @param the background color choosed by the sender.
 public void setBgcolor(String string) {
 bgcolor = string;
 * @param the font choosed by the sender.
 public void setFont(String string) {
 font = string;
 * @param the sender's email.
 public void setFrom_email(String string) {
 from_email = string;
 * @param the sender's name.
 public void setFrom_name(String string) {
 from_name = string;
 * @param the card's id.
 public void setId(long i) {
 id = i;
 * @param the image choosed by the sender.
 public void setImage(String string) {
 image = string;
 * @param the message input by the sender.
 public void setMessage(String string) {
 message = string;
 * @param <code>true</code> if the card has been received, <code>false</code> otherwise.
 * If the application attempts to set the received field to true,
 * then the received field of the Card object is persisted to database
 * and an email is sent to the sender to notify them that the card has been received.
 public void setReceived(boolean b) {
 if (this.received == false && b == true) {
 Mailer m = new Mailer();
 try {
 m.sendAcknowlegement(
 to_email,
 from_email,
 from_name,
 to_name,
 id);
 Connection con = DBConnection.getConnection();
 PreparedStatement ps =
 con.prepareStatement(Queries.setReceivedQuery);
 ps.setLong(1, this.id);
 ps.executeUpdate();
 con.close();
 this.received = true;
 } catch (Exception e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
 * @param <code>true</code> if the card has been sent, <code>false</code> otherwise.
 * If the application attempts to set the send field to true,
 * then the sent field of the Card object is persisted to database.
 public void setSent(boolean b) {
 if (this.sent == false && b == true) {
 try {
 Connection con = DBConnection.getConnection();
 PreparedStatement ps =
 con.prepareStatement(Queries.setSentQuery);
 ps.setLong(1, this.id);
 ps.executeUpdate();
 con.close();
 } catch (SQLException e) {
 log.error("ERROR: impossible to update the sent field");
 e.printStackTrace();
 * @param the title choosed by the sender.
 public void setTitle(String string) {
 title = string;
 * @param the recipient's email.
 public void setTo_email(String string) {
 to_email = string;
 * @param the recipient's name.
 public void setTo_name(String string) {
 to_name = string;
 * @return the send date.
 public String getSend_date() {
 return send_date;
 * @param the send date.
 public void setSend_date(String string) {
 send_date = string;
 * @return <code>true</code> if email has been sent, <code>false</code> otherwise.
 public boolean sendEmail() {
 try {
 Mailer sm = new Mailer();
 sm.sendCard(
 this.from_email,
 this.to_email,
 this.from_name,
 this.to_name,
 this.id);
 return true;
 } catch (Exception e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
 return false;
 * Retrieve the card from the database
 public static Card getCardFromId(int id) {
 Card c = new Card();
 c.id = id;
 try {
 Connection con = DBConnection.getConnection();
 PreparedStatement ps = con.prepareStatement(Queries.getCardFromID);
 ps.setInt(1, id);
 ResultSet rs = ps.executeQuery();
 if (rs.next()) {
 c.setBgcolor(rs.getString("db_bgcolor"));
 c.setFont(rs.getString("db_font"));
 c.setFrom_email(rs.getString("db_from_email"));
 c.setTo_email(rs.getString("db_to_email"));
 c.setFrom_name(rs.getString("db_from_name"));
 c.setTo_name(rs.getString("db_to_name"));
 c.setFont(rs.getString("db_font"));
 c.setMessage((String) rs.getObject("db_message"));
 c.setTitle(rs.getString("db_title"));
 c.setSend_date(rs.getString("db_send_date"));
 c.setImage(rs.getString("db_image"));
 if (rs.getString("db_received").equals("y")) {
 c.received = true;
 } else if (rs.getString("db_received").equals("n")) {
 c.setReceived(true);
 if (rs.getString("db_sent").equals("y")) {
 c.setSent(true);
 } else if (rs.getString("db_sent").equals("n")) {
 c.setSent(false);
 System.out.println(c);
 //con.close();
 return c;
 } catch (SQLException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
 return null;
 public String toString() {
 return ("Title: " + this.title + ", " + "Id: " + this.id);
 * @param string
 public void setResponse(String string) {
 response = string;
 protected String saveCard() {
 try {
 Connection con = DBConnection.getConnection();
 PreparedStatement ps = con.prepareStatement(Queries.saveCard);
 ps.setLong(1, (new java.util.Date()).getTime());
 ps.setString(2, this.from_email);
 ps.setString(3, this.to_email);
 ps.setString(4, this.image);
 ps.setString(5, this.bgcolor);
 ps.setString(6, this.font);
 ps.setString(7, this.from_name);
 ps.setString(8, this.to_name);
 ps.setString(9, this.message);
 ps.setString(10, this.title);
 ps.setString(11, this.send_date);
 ps.executeUpdate();
 con.close();
 return "saved";
 } catch (SQLException e) {
 log.error("ERROR: impossible to save the card");
 e.printStackTrace();
 return "notSaved";
 public Action getSaveCard() {
 return new Action() {
 public String invoke() {
 return saveCard();
}The full source code for the project can be downloaded here:
http://cours.java.free.fr/ecards-project/
I would like to decouple the bean from the jdbc but I don't know how to. Can anyone help please?
I found some sampes here http://access1.sun.com/codesamples/DataAccessObject.html
but it does not have any update jdbc.
Julien.

Your DAO should have methods for getting and setting beans.
For example:
public Card getCard(long id){...}
public void updateCard(Card c) {...}

Flex design pattern for BlazeDS transfer objects

Dear Community,
I have a question regarding the nature of objects transferd from BlazeDS backend to the Flex client.
According to some adobe docs all the presentation logic should be in flex and BlazeDS should provide only services.
The question is what kind of transfer objects should be used? with what level of abstraction?
To make it more clear let's talk about a simple forum application like adobe forums.
I have created a Forum service, which returns a Forum transfer object, which has a List of Threads, with each thread having a List of Messages.
Flex gets the Forum transfer object and does all the presentaiton work.
This is a very nice seperatin of concerns architecture BUT there are two major performance issues:
- when the forum becomes bigger the transfer object will be huge
- the flex will use huge client resources to create the presentation of the forum transfer object.
So my question is what is your strategy/ design pattern for such a problem.
An obvious answer would be create services that include the presentation logic and use transfor objects like ThreadListPage which will include only the first 10 threads.
Thanks in advance

I think you are going to get a few varied types of answers to a general question like this, but I will comment on a few things. First, you should only be transmitting the data that you need to use or display to the user at the time. If this forum was implemented in Flex (I wish) you wouldn't transfer the text for all the threads. You might not transfer the thread text at all (just the subjects), you'd make calls back to the server to fetch that data when and if you need it.
Also, I think you are overestimating the resources required for the Flex "presentation layer". If you think about it, these workstations we have here are pretty idle most of the time when you're at a website. Nowadays there's plenty of processing power just sitting there waiting, so as long as your design isn't flawed the CPU or memory are rarely going to be a bottleneck with Flex.
The way I design, BlazeDS (or GraniteDS etc) should mostly just be "serving data". There is some flexibility available, for example I don't see a problem with putting certain types of business rules (such as a limit on the number of results that can be recieved in a search) within server side code, and validation rules on the Flex side. So there's not too many "industry standards" in Flex yet beyond maybe what's done in the various standard architectures, at least not that I'm aware of.
You might find it beneficial to look into some of the various frameworks/architectures available like Cairngorm, Mate, Swiz, and so on. Learning how they work (looking at examples) would probably answer some of your questions too.

Transfer Object in JSF, Spring, and Hibernate

The application on which I am working deploys the JavaServer Faces, Spring and Hibernate frameworks.
We are going to use the "transfer object" to move data between J2EE tiers from the front end to the back end and vice versa. In addition, data "types" may need to be converted --
At the front end, the "type" of the data that are entered by users may not match that in the database table. For example, checkboxes may be marked or left blank by users. The "type" of the checkboxes is "boolean" in the JSF backing bean. However, we have either "Y" or "N" for the corresponding field in the database table.
The JSF backing bean holds data as well as controller functionality. Of course, the transfer object holds data only.
With regard to class properties, Is the transfer object an exact copy of the JSF backing bean? And at which tier the data are converted to match their correspoding "types" in the database tables?
We also have the "data objects" which are exact representation of database tables.
Thanks for your advices.

Small example: you can decide in the business layer
whether to convert it to boolean or Boolean (which
has a 3rd state: null).But it all goes back to your data model. If your data model supports null for that property, then of course boolean is a poor choice. If that case one could use Boolean. None of this has anything to do with re-usability, which was your objection.
I think the re-usability question goes back to the data model as well. Suppose your data model says this property is boolean valued. However if your database does not support booleans natively, then you need to map the value for storage in the database. But that is the data persistence layers problem.
OTOH, suppose your data model says that this property may be 'Y' or 'N'. Then the Java class represent the business object should not have a boolean property, we should make it match the data model.
However, I think that most cases where people are storing 'Y' or 'N' in a field in the database fall into the first case, where the data model is a boolean and they are working around limitations in the database. There is no reason in that case to perpetuate the same limitations in the Java code.

EJB3 & Patterns: Transfer Objects

EJB3 Entities look really nice, but I have a couple of slightly related questions...
Now that our entities are also POJOs, do we need the TO pattern all that much?
With EJB2 I would have the heavy entity/session beans create light POJO TOs to pass trough the session beans on to the client, this would decouple the clients from the entity beans and if we refactored the entities the clients wouldn't need to know as long as we didn't refactor the POJO TOs.
With EJB3, the entity beans are also POJOs when they leave the container... thus I don't have to write two sets of classes... but I lose the decoupling...
I'm not entirely sure I wanted the decoupling all that much for most of the time... and I suppose if we do refactor, I can just keep the former EJB3 Entity/POJO TO as a POJO TO and generate it from the now refactored EJB3 entities... but I'll still have the annotations in the class (unless I strip them... which means recompile the client) so now I have TOs which were EJB3 Entities and are still annotated as such, but which are not being used as such anymore... sounds like a mess!
And now for the more specific question:
@Entity
class Customer {
private List<Project> projects;
@OneToMany
public List<Project> getProjects() { /* ... */ }
@Entity
class Project {
private Customer customer;
private List<Task> tasks;
private boolean active;
@ManyToOne
public Customer getCustomer() { /* ... */ }
@OneToMany
public List<Task> getTasks () { /* ... */ }
public boolean isActive() { /* ... */ }
@Entity
class Task {
private Project project;
@ManyToOne
public Project getProject() { /* ... */ }
}Now in the above situation, customers have 100s to 1000s of projects each with 10s to 100s of tasks... i.e. the projects are not exactly light objects in and of themselves. (note: i've refactored the object names into a more easily identified problem domain)
I want to pass a customer object to the client app...
in some situations the client app does not need to know all the past projects of the customer, only the active ones
in other cases the client app needs to know nothing about projects (active or not)
in other cases the client app needs to know only the project names...
Question: (obviously we'll use LAZY fetching) what's going to happen to my customer entity when I detach it to use it as a TO?
Will it only have those child objects that I accessed before detaching? Or will it have the potentially megabytes of data for all the inactive projects and all their tasks? My guess is that it depends on the container... and it looks like I'm back to having building TOs in order to guarantee good performance across container vendors
Or have I got it all wrong?
Do I just have to have three getClient methods in my CustomerRepositoryBean...
public Customer findCustomer(...) /* before we detach, recurse all the projects and their associated tasks in the customer to ensure it's all been fetched */
public Customer findCustomerWithActiveProjectNamesOnly(...) /* before we detach, recurse all active projects, but only access the project name field of the projects */
public Customer findCustomerWithoutProjectDetail(...) /* detach without accessing the projects */

OK, I'm not the only person thinking that DTOs are note so necessary anymore with EJB3...
http://www.jroller.com/page/raghukodali?entry=dto_an_antipattern_in_ejb
But I'm wondering if I have a case for them with my code sample...

Unable to create Instance with Object Editor and Attachment Pattern

Hi Experts,
I created a simple entity service with some attributes and a document reference.
I also configured an object editor pattern and assigned a attachment pattern. The created object editor works as long as I don't attach a file. But if I attach a file and want to save it I get an error message "cannot create"
In the default log.trc I have some entries
Cannot read associated instance with MOF ID 105D8E0C4F02D45AFFD5B9D6A09EFB7A of MOF Layer 2 for (6DC24B80F6004CDBF4FA6C560AEDD33C,<null>)
and
refPackageM1(com.sap.ip.bi.sdk.dac.olap.query) failed RepositoryDBMemory. Using generic one.
I configured the j2ee engine according the tutorial "Integrating KM with CAF UI Patterns"
So what is wrong?
Best regards Manuel

Hi,
From the stacktrace I assume that the following happens (please correct me, if I'm wrong):
* Some time based event mechanism sends an event to your custom event handler code. That code is execute in some system context.
* Your handler uses the RF API to create a collection. All this is perfectly OK. Here my assumptions end, the next steps are solid facts.
* Within the RF all property filters are informed that a resource is about to be created. One of the filters is trying to obtain a lock from a system provided Locking Service.
* That service refuses to grant the lock, telling that system users are not allowed to do so.
Most proably you cannot do anything to solve this problem by yourself. When I ran into the same Exception once, I could avoid to have my code run in a system thread. Well you might try to do the same.
Otherwise please open a customer message and complain about the restiction in the locking behaviour.
Best regards,
Michael

Object Oriented Patterns and Visio

Visio question:
Does anyone know if there are established shapes for each (or any) of the object oriented patterns? If not, is anyone working on that or interested in that?
Since they all have names (Momento, Proxy, Iterator, Mediator, Observer, etc.) it seems like they ought to each have their own shape. Since Object Oriented is all about communication of intent, each pattern having its own recognizable shape would go a long way toward a more meaningful communication through diagram. Also, if they each had their own shape, then the super-patterns (based on commonly grouped patterns and interactions) could also be easily represented.
Blaine

I'm kind of making an assumption here and if it's in error then feel free to disregard the rest of this post.
Assumption that you're thinking terms of shapes for representing in UML the various patterns. Everything you need is right there in front of you already regardless of whether you use Visio, Rational, Poseidon or some other UML tool.
Patterns are not individual constructs. One does not make a Mediator class. One makes a Java class that is an implementation of the Mediator pattern. As such you would see in the static class diagram the same grouping of classes for an X Mediator as you would for Y Mediator. That is the image you're looking for. It's not a single widget that you drag onto the screen, it's in the pattern itself.
If, however, you're talking about something like a graphical representation to give to managers that says "Here be Momento patterns", then I would postulate that you're trying to communicate information that they don't need nor should they concern themselves with. Patterns are an implementation issue. They deal with, "How" we will solve a problem, not what problem will we solve. Mangaers, IMNSHO, need only concern themselves with what problems we will solve, not how they will be solved.
Just my 2 krupplenicks on the subject, your milage may of course vary.
PS.

Cheat Sheet/Listing of Object types and transactions they are available in?

Does anyone know how to obtain a listing of the standard object types and where they would be available?
We have already worked with the Travel Management Trip Docuemnts and I know that object type BUS2089 is available through the Object for Services area of transaction PR05. So we store entries in the TOA01 table for this object and they are available to us in the object services section.
But now we want to leverage the functionality we built and extend it to other areas. But I spent a lot of time today trying to find out what object could be used through transaction IE03 for an equipment record and finally found EQUI. Now I just have to test it out.
I see a lot of standard document types available as well and don't know what they are for - for Plant Maintenance work order notifications object type BUS2038 is there with PMONOTFPAP, PMIDAMAGE and PMIREQUEST already available. I didn't want to create a new one if these are available for work order notification images, etc.
It would be nice if there was a spreadsheet or listing that detailed each object type and where it was used in the system.
(I did try searching but didn't find this question/answer on a broad basis.)

Tarun,
Thanks for replying. I think that we are agreeing on the same details, but it doesn't really answer my question.
I guess what I am looking for is if I asked the following question:
     What object type is used when populating the object services link from within an equipment record via IE03?
How would you obtain the answer to this question - besides just knowing it?
It's the same way that I know the following:
     What object type is used when populating the object services link from within a trip via PR05? --> BUS2089
     What object type is used when populating the object services link from within a work order via IW33? --> BUS2007
     What object type is used when populating the object services link from within a wo notification via IW23? --> BUS2038
The last two were easy because it prompts you when creating an attachment. The first one someone told me the answer to.
We will be doing image links for many different documents (invoices, journal entries, HR employee records, etc) and I'm just trying to figure out how to know which objects to use. Once I know the object I know how to configure the OAC* tables for use.
Any help is much appreciated.
Thanks!

Transaction SMOEAC does not display Object type and Object Name options.

Dear all,
When I go to transaction SMOEAC system does not display fields Object type and Object Name option instead displays an empty frame allowing only to create new objects.
System does not allow and display existing objects to edit.
Most imp with the same ID, I am able to see the existing objects and two fields "Object type" and "Object Name" on different machine. So there is no authorization issue.
My SAP GUI version where these fields are not visible is 640 Final Release with 6405.5.18.1016 version and Patch level 18.
My SAP GUI version here these fields are visible is 640 Final Release with 6404.4.14.1012 version and Patch Level 14.
Any idea what could be the reason?
Regards,
Sandeep Parab

With installation of latest version of SAP GUI 710 final Release resolved my problem.
Regards,
Sandeep

Diff between a concurrent mgr and a transaction mgr

hi,
1)may i know what is tthe difference between a conn.mgr and a transaction.mgr?
(i came to know that in tran.mgr, the request won't go to database) if the request is not going to database then how the request is going to be processed by transaction mgr? and in which cases we will go for transaction manager(give me some eg's)
2)internal manager and internal concurrent mgr are they same?
Thanks and Regards
Srikanth

Srikanth,
1) As you have said, requests for a transaction manager don't go through the FND_CONCURRENT_REQUESTS table as they do for a normal concurrent manager. My understanding is that requests are sent to the transaction manager through database pipes (ie the DBMS_PIPE package). Each transaction manager process listens on a pipe for work requests. Processing requiring a transaction manager pings the related pipes, to find one that is ready to process the action.
We haven't written any custom transaction managers, but the standard ones seem to be used where you might want effectively real-time processing that isn't expected to take much time by the manager (ie PO/Requisition Approvals) without having to wait for the concurrent manager to poll for pending requests.
2) As far as I know, the internal manager and internal concurrent manager are the same.

String.matches vs Pattern and Matcher object

Hi,
I was trying to match some regex using String.matches but for me it is not working (probably I am not using it the way it should be used).
Here is a simple example:
/* This does not work */
String patternStr = "a";
String inputStr = "abc";
if(inputStr.matches( "a" ))
System.out.println("String matched");
/* This works */
Pattern p = Pattern.compile( "a" );
Matcher m = p.matcher( "abc" );
boolean found = false;
while(m.find())
System.out.println("Matched using Pattern and Matcher");
found = true;
if(!found)
System.out.println("Not matching with Pattern and Matcher");
Am I not matches method of String class properly?
Please throw some lights on this.
Thank you.

String.matches looks at the whole string.
bsh % "abc".matches("a");
<false>
bsh % "abc".matches("a.*");
<true>

Transfer Object Pattern and Concurrency Transaction Mgmt

Similar Messages

Maybe you are looking for