-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: No DTOs
PostPosted: Tue Aug 03, 2004 6:44 pm 
Newbie

Joined: Wed Jun 23, 2004 8:51 pm
Posts: 16
Say I've got domain objects "Order" and "FinanceRecord" which I'll use Hibernate to map to the database.

Could my code look like this? Is there anything wrong with this design?

Code:
  public class Order{
    //getters and setters
    public void createFinanceRecord(){
      FinanceRecord fr = new FinanceRecord();
      fr.setOrder(this);
      ...
      DAO.getInstance().saveOrUpdate(fr);
      ...
     }
  }


I use a DAO "DAO.getInstance()" so I'm not tied to Hibernate.

So now if I want to go without DTOs, I'd have these classes on the client side.

Therefore, I had to use a DAO so I don't need Hibernate on the client side?

So I've got this method "createFinanceRecord()" on the client side, which I can't call that contains business logic that the client shouldn't need to know about.
This is not a problem except that it's not too elegant.

If I did call createFinanceRecord() on the client side DAO.getInstance() would return null and I'd get a null pointer, which is fine.

Does this all look OK in theory?
Does anything I said not make sense?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 04, 2004 2:18 pm 
CGLIB Developer
CGLIB Developer

Joined: Thu Aug 28, 2003 1:44 pm
Posts: 1217
Location: Vilnius, Lithuania
it must be better to use "DAO.getInstance().createFinanceRecord(order)" in theory, your model will be more reusable without noise like persistence.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 05, 2004 7:11 pm 
Newbie

Joined: Wed Jun 23, 2004 8:51 pm
Posts: 16
baliukas wrote:
it must be better to use "DAO.getInstance().createFinanceRecord(order)" in theory, your model will be more reusable without noise like persistence.

I'm not sure about this approach...
If I put business logic in my DAO classes, I'll end up with a lot of methods on my DAO classes? Is this better than having the business logic in the POJO?

"your model will be more reusable without noise like persistence."
-I didn't quite understand this comment fully.

How about this example?

Code:
public class Order{
    //getters and setters
    public FinanceRecord getCurrentFinanceRecord(){
      FinanceRecord[] frs = getFinanceRecords();
      long status = FinanceDAO.getInstance().getStatus("current");

      for(i == 0; i < frs.length; i++){
        FinanceRecord fr = frs[i];
        if(fr.getStatus() == status){
          return fr;
        }
      }
      return null;
     }
  }


Would you do it this way? or have
DAO.getInstance().getCurrentFinanceRecord(order) ?

Also, for this particular example (cause it's read only), I suppose you could have a client side version of FinanceDAO.getInstance() that made a call back to the server or cache etc.

Any thoughts?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2004 4:54 am 
CGLIB Developer
CGLIB Developer

Joined: Thu Aug 28, 2003 1:44 pm
Posts: 1217
Location: Vilnius, Lithuania
Your first example was better motyvated, you access "this" in "createFinanceRecord", in the next exapmle you can declare "getCurrentFinanceRecord" as static and it is the same as DAO, just in different namespace).

You need persistent instance to call this method, it is not a very big problem in practice if you do not load it.

Model is not "reusable" if it declares or calls access methods in domain object like "parseFile","loadFromDB", "getRemote".
As I understand "FinanceDAO.getInstance().getStatus("current");" is an access method call if system is distributed, but it can be not a problem for you too.

So I think this stuff can be better in theory, but I do not know your application and just ignore any recomendation if it is not motyvated for your problem.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.