2 Replies - 154 Views - Last Post: 04 May 2019 - 04:48 PM Rate Topic: -----

#1 Zoshenkov   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 10
  • Joined: 03-August 16

Best practices/avoiding pitfalls when changing DTO(s)?

Posted 04 May 2019 - 07:35 AM

Ok, now this is what I was tasked for:

To read an old project, grasp as much of it as possible within a limited time-frame, and then restructure the old code for interacting with an old database to a new one.

Now you have a rough idea, here's the elaboration:

The old code interact with a DB which has Name, Age, Student_number etc. The New code interact with a DB which has Name, nick_name, Age, credit_standing, etc. In other words, some columns in the DB will remain the same with only name changes, some will be completely different (new columns or old ones gone), and here's the worst part, what was grouped in one table will be split into 2 and vice versa.

So the question I'm asking is: Can you please give me tips and suggestions on avoiding as many pitfalls/headaches when doing this as possible? I don't have any tricks up my sleeves to make this as un-hellish as possible. This is actually a fairly new challenge for me.

About the code: it has a wrapped DTO class, with things like Name, Age etc. etc. encapsulated together. But the fields (which corresponds to columns in the DB) isn't enough, I'll need more. Also although the original author tried to wrap everything nicely in one place as much as possible, he still ended up getting things all over several different modules so I may need to snipe them out one by one.

Last but not least, this is what I'm planning to do:

Divide and conquer, take care of the DTO class first, build a child class which uses as much the old DTO's fields as possible, except when it comes to getters and setters, I use a different name, for example, in the old DTO, there was:

public void getID(){return this.ID;}


in my new code it will be like:

public void getID(){return this.studentID;}


So I don't have to modify a whole lot of other code, and my new DTO will still be called, for example:

public class someClassUsesDTO{
    dbDTO dto = new dbDTO();
    
    this.id = dto.getID();

}


Even though the dbDTO has been replaced with the new one, the old code should still work.

So, any great ideas and suggestions?

PS: sorry for completely botched up terminologies, I still couldn't figure out what is what even though I know roughly where I should apply them.

Is This A Good Question/Topic? 0
  • +

Replies To: Best practices/avoiding pitfalls when changing DTO(s)?

#2 Zoshenkov   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 10
  • Joined: 03-August 16

Re: Best practices/avoiding pitfalls when changing DTO(s)?

Posted 04 May 2019 - 07:40 AM

ADD:

Can't seem to modify. A few things to clear up:

By " except when it comes to getters and setters, I use a different name, " I mean to use different field variable names, the name of the getters and setters will be the same of course, or it would be completely missing the point.

By "divide and conquer", I mean to take care of the elephant in the room, that DTO class which encapsulated a great deal of data inside itself first, then other scattered, spread out data one by one later.
Was This Post Helpful? 0
  • +
  • -

#3 veretimothy   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 5
  • Joined: 01-April 19

Re: Best practices/avoiding pitfalls when changing DTO(s)?

Posted 04 May 2019 - 04:48 PM

Need to use reflection mechanism and xml

<xml>
  <bean id="dto" class="com.db.DBDTO" />
</xml>



Create a class CBean, Reflection instantiation class="com.db.DBDTO"

public class someClassUsesDTO{
    dbDTO dto = CBean.getBean("dto");
    this.id = dto.getID();
}



if something new dbDTO , you just need modify xml config <bean id="dto" class="com.db.DBDTO" /> , don't need modify code.

Here is example:

en.verejava.com/?id=20004233133445
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1