Best Practices

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Best Practices

Padam J Singh
I will be doing  code re-factoring for a project about three years old
with about a thousand queries being executed via iBatis.

There are two distinct patterns I see in the project

1. resultClass as a HashMap
2. resultClass as a POJO (There are about 10 POJO with about 50
members each, and not every member is used in every query)

I want to make a consistent use across the project, and can't decide
which is better.

Is there a guideline/best practice I can follow and use one pattern?

Thanks!
Padam
Tim
Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Tim
Best practice says to return resultClasses as a single string value.
It should be something like "foo{a=1,b=2}" for ease of use.

On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]> wrote:

> I will be doing  code re-factoring for a project about three years old
> with about a thousand queries being executed via iBatis.
>
> There are two distinct patterns I see in the project
>
> 1. resultClass as a HashMap
> 2. resultClass as a POJO (There are about 10 POJO with about 50
> members each, and not every member is used in every query)
>
> I want to make a consistent use across the project, and can't decide
> which is better.
>
> Is there a guideline/best practice I can follow and use one pattern?
>
> Thanks!
> Padam
Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Larry Meadors
Hm, I think Tim's smoking crack. ;-)

I use beans as a rule.

Larry


On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]> wrote:

> Best practice says to return resultClasses as a single string value.
> It should be something like "foo{a=1,b=2}" for ease of use.
>
> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]> wrote:
>> I will be doing  code re-factoring for a project about three years old
>> with about a thousand queries being executed via iBatis.
>>
>> There are two distinct patterns I see in the project
>>
>> 1. resultClass as a HashMap
>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>> members each, and not every member is used in every query)
>>
>> I want to make a consistent use across the project, and can't decide
>> which is better.
>>
>> Is there a guideline/best practice I can follow and use one pattern?
>>
>> Thanks!
>> Padam
>
Tim
Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Tim
No way. If you use a single string then you can build abstract
factories of factories of builders for them.
Think of the overcompontiflication!! I think it would be glorious.

On Thu, Sep 9, 2010 at 2:55 PM, Larry Meadors <[hidden email]> wrote:

> Hm, I think Tim's smoking crack. ;-)
>
> I use beans as a rule.
>
> Larry
>
>
> On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]> wrote:
>> Best practice says to return resultClasses as a single string value.
>> It should be something like "foo{a=1,b=2}" for ease of use.
>>
>> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]> wrote:
>>> I will be doing  code re-factoring for a project about three years old
>>> with about a thousand queries being executed via iBatis.
>>>
>>> There are two distinct patterns I see in the project
>>>
>>> 1. resultClass as a HashMap
>>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>>> members each, and not every member is used in every query)
>>>
>>> I want to make a consistent use across the project, and can't decide
>>> which is better.
>>>
>>> Is there a guideline/best practice I can follow and use one pattern?
>>>
>>> Thanks!
>>> Padam
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Padam J Singh
In reply to this post by Larry Meadors
I agree with you on both points :-)


The only negative thing about having resultClass as beans is that you
end up having beans that keep getting large - a query returning two
columns being populated into a bean with 30 members wastes a lot of memory.

I think the only way to rationalize this would be to have a more bean
classes to avoid high number of members per class, and that becomes
another topic on maintainability...

Padam

On 10/09/10 1:25 , Larry Meadors wrote:

> Hm, I think Tim's smoking crack. ;-)
>
> I use beans as a rule.
>
> Larry
>
>
> On Thu, Sep 9, 2010 at 1:44 PM, Tim<[hidden email]>  wrote:
>> Best practice says to return resultClasses as a single string value.
>> It should be something like "foo{a=1,b=2}" for ease of use.
>>
>> On Thu, Sep 9, 2010 at 2:39 PM, Padam<[hidden email]>  wrote:
>>> I will be doing  code re-factoring for a project about three years old
>>> with about a thousand queries being executed via iBatis.
>>>
>>> There are two distinct patterns I see in the project
>>>
>>> 1. resultClass as a HashMap
>>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>>> members each, and not every member is used in every query)
>>>
>>> I want to make a consistent use across the project, and can't decide
>>> which is better.
>>>
>>> Is there a guideline/best practice I can follow and use one pattern?
>>>
>>> Thanks!
>>> Padam
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: Best Practices

Rick.Wellman
Without going into the history of the current project I'm working on,
let me say this which I have learned from this project:
Unless there is a *very* specific reason you are that concerned with
memory usage, then it should be virtually the *least* of your concerns.
If you are operating on a "domain object"/bean that you retrieve from
the database via iBatis, then you want it to be a complete JavaBean with
*all* of its properties defined.  Whether or not you use/display all of
those properties depends on the use-case.  IMHO, to try and control the
amount of properties which are "valid" based on the use-case is a road
less travelled (for good reason).

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Padam J Singh
Sent: Thursday, September 09, 2010 3:06 PM
To: [hidden email]
Subject: Re: Best Practices

I agree with you on both points :-)


The only negative thing about having resultClass as beans is that you
end up having beans that keep getting large - a query returning two
columns being populated into a bean with 30 members wastes a lot of
memory.

I think the only way to rationalize this would be to have a more bean
classes to avoid high number of members per class, and that becomes
another topic on maintainability...

Padam

On 10/09/10 1:25 , Larry Meadors wrote:

> Hm, I think Tim's smoking crack. ;-)
>
> I use beans as a rule.
>
> Larry
>
>
> On Thu, Sep 9, 2010 at 1:44 PM, Tim<[hidden email]>  wrote:
>> Best practice says to return resultClasses as a single string value.
>> It should be something like "foo{a=1,b=2}" for ease of use.
>>
>> On Thu, Sep 9, 2010 at 2:39 PM, Padam<[hidden email]>  wrote:
>>> I will be doing  code re-factoring for a project about three years
old

>>> with about a thousand queries being executed via iBatis.
>>>
>>> There are two distinct patterns I see in the project
>>>
>>> 1. resultClass as a HashMap
>>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>>> members each, and not every member is used in every query)
>>>
>>> I want to make a consistent use across the project, and can't decide
>>> which is better.
>>>
>>> Is there a guideline/best practice I can follow and use one pattern?
>>>
>>> Thanks!
>>> Padam
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Brandon Goodin
In reply to this post by Tim
overcompontiplification - actively pontificating a solution that is more complex than the problem.

Eager use of the word Tim. You make me proud. Just watch the spelling next time :D 

Maps require more typing on the result map side and will introduce ambiguities. Beans have their typing built in. The memory really shouldn't be that huge of an issue. I tend to go with beans. It is a rare occasion that I use a map intentionally. Additionally, with beans you get all that handy dandy code completion in your IDE.

The fact that they created a handful of beans to service a thousand queries seems a bit odd. I think you should start migrating the code-base to use unique beans where appropriate instead of having "potential use" properties hanging out on a handful of beans.

If you provide some more concrete examples we can likely give you some more solid advice. 

I would augment Tim's advice and encourage you to exclusively use maps as your regular result class, pass it into a RowHandler, assemble it as YAML, then setup your data access layer as a web service (to be SOA compliant), and pass the YAML back so that it is easily consumable by the requestor. Now THAT would be glorious overcompontiplification. P.S This last paragraph is a joke.

Brandon

On Thu, Sep 9, 2010 at 2:57 PM, Tim <[hidden email]> wrote:
No way. If you use a single string then you can build abstract
factories of factories of builders for them.
Think of the overcompontiflication!! I think it would be glorious.

On Thu, Sep 9, 2010 at 2:55 PM, Larry Meadors <[hidden email]> wrote:
> Hm, I think Tim's smoking crack. ;-)
>
> I use beans as a rule.
>
> Larry
>
>
> On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]> wrote:
>> Best practice says to return resultClasses as a single string value.
>> It should be something like "foo{a=1,b=2}" for ease of use.
>>
>> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]> wrote:
>>> I will be doing  code re-factoring for a project about three years old
>>> with about a thousand queries being executed via iBatis.
>>>
>>> There are two distinct patterns I see in the project
>>>
>>> 1. resultClass as a HashMap
>>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>>> members each, and not every member is used in every query)
>>>
>>> I want to make a consistent use across the project, and can't decide
>>> which is better.
>>>
>>> Is there a guideline/best practice I can follow and use one pattern?
>>>
>>> Thanks!
>>> Padam
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Padam J Singh
On 10/09/10 2:00 , Brandon Goodin wrote:

> overcompontiplification - actively pontificating a solution that is more
> complex than the problem.
>
> Eager use of the word Tim. You make me proud. Just watch the spelling
> next time :D
>
> Maps require more typing on the result map side and will introduce
> ambiguities. Beans have their typing built in. The memory really
> shouldn't be that huge of an issue. I tend to go with beans. It is a
> rare occasion that I use a map intentionally. Additionally, with beans
> you get all that handy dandy code completion in your IDE.
>
> The fact that they created a handful of beans to service a thousand
> queries seems a bit odd. I think you should start migrating the
> code-base to use unique beans where appropriate instead of having
> "potential use" properties hanging out on a handful of beans.
>
Wouldn't this itself lead to hundreds (if not thousands) of beans?

> If you provide some more concrete examples we can likely give you some
> more solid advice.
>

The application is based around Struts framework and uses display tag
library (http://displaytag.sourceforge.net/1.2/) in addition to struts
own taglibs. A request is parsed, then the model code does all the
processing. Some model code returns List of Beans or List of HashMaps
which are then used in the JSP files using the display tag lib to
automatically create nice looking tabular data. Good thing about using
display tag libs is that it doesnt matter if the list contains beans or
maps, so I can change the list without breaking code in the JSPs.

The other use is for forms. A bean is populated from the DB, then bean
properties are copied over to the Form bean, which are then rendered in
the JSP with all form elements generated using the struts tag lib.


> I would augment Tim's advice and encourage you to exclusively use maps
> as your regular result class, pass it into a RowHandler, assemble it as
> YAML, then setup your data access layer as a web service (to be SOA
> compliant), and pass the YAML back so that it is easily consumable by
> the requestor. Now THAT would be glorious overcompontiplification. P.S
> This last paragraph is a joke.
>
:-)

> Brandon
>
> On Thu, Sep 9, 2010 at 2:57 PM, Tim <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     No way. If you use a single string then you can build abstract
>     factories of factories of builders for them.
>     Think of the overcompontiflication!! I think it would be glorious.
>
>     On Thu, Sep 9, 2010 at 2:55 PM, Larry Meadors
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      > Hm, I think Tim's smoking crack. ;-)
>      >
>      > I use beans as a rule.
>      >
>      > Larry
>      >
>      >
>      > On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >> Best practice says to return resultClasses as a single string value.
>      >> It should be something like "foo{a=1,b=2}" for ease of use.
>      >>
>      >> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>> I will be doing  code re-factoring for a project about three
>     years old
>      >>> with about a thousand queries being executed via iBatis.
>      >>>
>      >>> There are two distinct patterns I see in the project
>      >>>
>      >>> 1. resultClass as a HashMap
>      >>> 2. resultClass as a POJO (There are about 10 POJO with about 50
>      >>> members each, and not every member is used in every query)
>      >>>
>      >>> I want to make a consistent use across the project, and can't
>     decide
>      >>> which is better.
>      >>>
>      >>> Is there a guideline/best practice I can follow and use one
>     pattern?
>      >>>
>      >>> Thanks!
>      >>> Padam
>      >>
>      >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Brandon Goodin
It seems to me this app has bigger issues than just whether you should pass back a bean or a map from MyBatis. The best practice is to pass back beans. You may need to go back and make some better decisions in the rest of the app design as to what should and should not be sharing beans. Even more fundamental than that you may need to make a strong effort to upgrade to a modern framework. The old Struts Action/Form is getting quite aged now. I shivered when you talked about copying properties. :)

Brandon


On Thu, Sep 9, 2010 at 3:59 PM, Padam J Singh <[hidden email]> wrote:
On 10/09/10 2:00 , Brandon Goodin wrote:
overcompontiplification - actively pontificating a solution that is more
complex than the problem.

Eager use of the word Tim. You make me proud. Just watch the spelling
next time :D

Maps require more typing on the result map side and will introduce
ambiguities. Beans have their typing built in. The memory really
shouldn't be that huge of an issue. I tend to go with beans. It is a
rare occasion that I use a map intentionally. Additionally, with beans
you get all that handy dandy code completion in your IDE.

The fact that they created a handful of beans to service a thousand
queries seems a bit odd. I think you should start migrating the
code-base to use unique beans where appropriate instead of having
"potential use" properties hanging out on a handful of beans.

Wouldn't this itself lead to hundreds (if not thousands) of beans?


If you provide some more concrete examples we can likely give you some
more solid advice.


The application is based around Struts framework and uses display tag library (http://displaytag.sourceforge.net/1.2/) in addition to struts own taglibs. A request is parsed, then the model code does all the processing. Some model code returns List of Beans or List of HashMaps which are then used in the JSP files using the display tag lib to automatically create nice looking tabular data. Good thing about using display tag libs is that it doesnt matter if the list contains beans or maps, so I can change the list without breaking code in the JSPs.

The other use is for forms. A bean is populated from the DB, then bean properties are copied over to the Form bean, which are then rendered in the JSP with all form elements generated using the struts tag lib.



I would augment Tim's advice and encourage you to exclusively use maps
as your regular result class, pass it into a RowHandler, assemble it as
YAML, then setup your data access layer as a web service (to be SOA
compliant), and pass the YAML back so that it is easily consumable by
the requestor. Now THAT would be glorious overcompontiplification. P.S
This last paragraph is a joke.

:-)
Brandon

On Thu, Sep 9, 2010 at 2:57 PM, Tim <[hidden email]
<mailto:[hidden email]>> wrote:

   No way. If you use a single string then you can build abstract
   factories of factories of builders for them.
   Think of the overcompontiflication!! I think it would be glorious.

   On Thu, Sep 9, 2010 at 2:55 PM, Larry Meadors
   <[hidden email] <mailto:[hidden email]>> wrote:
    > Hm, I think Tim's smoking crack. ;-)
    >
    > I use beans as a rule.
    >
    > Larry
    >
    >
    > On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]
   <mailto:[hidden email]>> wrote:
    >> Best practice says to return resultClasses as a single string value.
    >> It should be something like "foo{a=1,b=2}" for ease of use.
    >>
    >> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]
   <mailto:[hidden email]>> wrote:
    >>> I will be doing  code re-factoring for a project about three
   years old
    >>> with about a thousand queries being executed via iBatis.
    >>>
    >>> There are two distinct patterns I see in the project
    >>>
    >>> 1. resultClass as a HashMap
    >>> 2. resultClass as a POJO (There are about 10 POJO with about 50
    >>> members each, and not every member is used in every query)
    >>>
    >>> I want to make a consistent use across the project, and can't
   decide
    >>> which is better.
    >>>
    >>> Is there a guideline/best practice I can follow and use one
   pattern?
    >>>
    >>> Thanks!
    >>> Padam
    >>
    >




Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Larry Meadors
In reply to this post by Padam J Singh
On Thu, Sep 9, 2010 at 2:59 PM, Padam J Singh <[hidden email]> wrote:
> Wouldn't this itself lead to hundreds (if not thousands) of beans?

Boy, I guess it could, but sheesh, I think i would prefer that over
hundreds (if not thousands) of arbitrary Map structures.

For that matter, I think I'd prefer a punch in the throat to hundreds
(if not thousands) of arbitrary Map structures. :-P

> The application is based around Struts framework and uses display tag
> library (http://displaytag.sourceforge.net/1.2/) in addition to struts own
> taglibs. A request is parsed, then the model code does all the processing.

Ouch. Struts and the display taglib. Sorry.

> Some model code returns List of Beans or List of HashMaps which are then
> used in the JSP files using the display tag lib to automatically create nice
> looking tabular data. Good thing about using display tag libs is that it
> doesnt matter if the list contains beans or maps, so I can change the list
> without breaking code in the JSPs.

That's jsp in general.

> The other use is for forms. A bean is populated from the DB, then bean
> properties are copied over to the Form bean, which are then rendered in the
> JSP with all form elements generated using the struts tag lib.

You might consider using nested beans - so you have "form.user.name"
instead of just "form.name" - it'll cut the complexity of your form
objects (and total code) by 1/2 or more.

Larry
Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Brandon Goodin
In reply to this post by Padam J Singh
To add one more thought. I tend to have approximately a bean per database table. I'll extend those beans at times whenever I need to join some tables and add some human "human readable" data.

For example:

If I have a User table and a UserType table.

The UserType table may have id, name, description columns.
The User has a userTypeId field.

I may create a UserExpanded extends User and adds a userTypeName field.
In the query I'm joining User to UserType and reading the UserType.name column into the User.userTypeName field.

At times when I have a report query I will create a report bean and read the results with a RowHandler. In the RowHandler I total values from various fields in the beans and store them in an object on the RowHandler and return as a single object. The results and totals. This makes it super easy to pass to a page for display.

Brandon


On Thu, Sep 9, 2010 at 3:59 PM, Padam J Singh <[hidden email]> wrote:
On 10/09/10 2:00 , Brandon Goodin wrote:
overcompontiplification - actively pontificating a solution that is more
complex than the problem.

Eager use of the word Tim. You make me proud. Just watch the spelling
next time :D

Maps require more typing on the result map side and will introduce
ambiguities. Beans have their typing built in. The memory really
shouldn't be that huge of an issue. I tend to go with beans. It is a
rare occasion that I use a map intentionally. Additionally, with beans
you get all that handy dandy code completion in your IDE.

The fact that they created a handful of beans to service a thousand
queries seems a bit odd. I think you should start migrating the
code-base to use unique beans where appropriate instead of having
"potential use" properties hanging out on a handful of beans.

Wouldn't this itself lead to hundreds (if not thousands) of beans?


If you provide some more concrete examples we can likely give you some
more solid advice.


The application is based around Struts framework and uses display tag library (http://displaytag.sourceforge.net/1.2/) in addition to struts own taglibs. A request is parsed, then the model code does all the processing. Some model code returns List of Beans or List of HashMaps which are then used in the JSP files using the display tag lib to automatically create nice looking tabular data. Good thing about using display tag libs is that it doesnt matter if the list contains beans or maps, so I can change the list without breaking code in the JSPs.

The other use is for forms. A bean is populated from the DB, then bean properties are copied over to the Form bean, which are then rendered in the JSP with all form elements generated using the struts tag lib.



I would augment Tim's advice and encourage you to exclusively use maps
as your regular result class, pass it into a RowHandler, assemble it as
YAML, then setup your data access layer as a web service (to be SOA
compliant), and pass the YAML back so that it is easily consumable by
the requestor. Now THAT would be glorious overcompontiplification. P.S
This last paragraph is a joke.

:-)
Brandon

On Thu, Sep 9, 2010 at 2:57 PM, Tim <[hidden email]
<mailto:[hidden email]>> wrote:

   No way. If you use a single string then you can build abstract
   factories of factories of builders for them.
   Think of the overcompontiflication!! I think it would be glorious.

   On Thu, Sep 9, 2010 at 2:55 PM, Larry Meadors
   <[hidden email] <mailto:[hidden email]>> wrote:
    > Hm, I think Tim's smoking crack. ;-)
    >
    > I use beans as a rule.
    >
    > Larry
    >
    >
    > On Thu, Sep 9, 2010 at 1:44 PM, Tim <[hidden email]
   <mailto:[hidden email]>> wrote:
    >> Best practice says to return resultClasses as a single string value.
    >> It should be something like "foo{a=1,b=2}" for ease of use.
    >>
    >> On Thu, Sep 9, 2010 at 2:39 PM, Padam <[hidden email]
   <mailto:[hidden email]>> wrote:
    >>> I will be doing  code re-factoring for a project about three
   years old
    >>> with about a thousand queries being executed via iBatis.
    >>>
    >>> There are two distinct patterns I see in the project
    >>>
    >>> 1. resultClass as a HashMap
    >>> 2. resultClass as a POJO (There are about 10 POJO with about 50
    >>> members each, and not every member is used in every query)
    >>>
    >>> I want to make a consistent use across the project, and can't
   decide
    >>> which is better.
    >>>
    >>> Is there a guideline/best practice I can follow and use one
   pattern?
    >>>
    >>> Thanks!
    >>> Padam
    >>
    >




Reply | Threaded
Open this post in threaded view
|

Re: Best Practices

Padam J Singh
In reply to this post by Larry Meadors
On 10/09/10 2:51 , Larry Meadors wrote:
> On Thu, Sep 9, 2010 at 2:59 PM, Padam J Singh<[hidden email]>  wrote:
>> Wouldn't this itself lead to hundreds (if not thousands) of beans?
>
> Boy, I guess it could, but sheesh, I think i would prefer that over
> hundreds (if not thousands) of arbitrary Map structures.
>
> For that matter, I think I'd prefer a punch in the throat to hundreds
> (if not thousands) of arbitrary Map structures. :-P
>
I am convinced - beans is a better solution.
>> The application is based around Struts framework and uses display tag
>> library (http://displaytag.sourceforge.net/1.2/) in addition to struts own
>> taglibs. A request is parsed, then the model code does all the processing.
>
> Ouch. Struts and the display taglib. Sorry.
Yup - old app. Phase one is code cleanup. Later on migrate to Spring.

>
>> Some model code returns List of Beans or List of HashMaps which are then
>> used in the JSP files using the display tag lib to automatically create nice
>> looking tabular data. Good thing about using display tag libs is that it
>> doesnt matter if the list contains beans or maps, so I can change the list
>> without breaking code in the JSPs.
>
> That's jsp in general.
>
>> The other use is for forms. A bean is populated from the DB, then bean
>> properties are copied over to the Form bean, which are then rendered in the
>> JSP with all form elements generated using the struts tag lib.
>
> You might consider using nested beans - so you have "form.user.name"
> instead of just "form.name" - it'll cut the complexity of your form
> objects (and total code) by 1/2 or more.
Sounds Interesting. Will have a look on how to use this.
>
> Larry
>