continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Thakur <rahul.thakur.x...@gmail.com>
Subject Re: ContinuumStore refactoring
Date Tue, 29 Apr 2008 03:57:51 GMT
Hi Emmanuel,

Just wondering if you hacked some samples? :-)

Cheers,
Rahul



Emmanuel Venisse wrote:
> I'll create some examples asap.
>
> Emmanuel
>
> On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur<rahul.thakur.xdev@gmail.com>
> wrote:
>
>> Hi,
>>
>> Some code using a couple of Entities as examples would be nice :-)
>>
>> I still think the API would be verbose.
>>
>> Thanks,
>> Rahul
>>
>>
>> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
>> <emmanuel.venisse@gmail.com>  wrote:
>>>
>>>
>>>
>>> On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur<
>> rahul.thakur.xdev@gmail.com>
>>> wrote:
>>>>
>>>>>> 2)   Criteria vs Named Queries: I am not convinced (yet) that Named
>>>>>> queries are the way to go. I did some digging around, they are
>> indeed
>>>>>> best practices for JPA but I think the decision merits other
>>>>>> consideration(s). I still believe the Criteria Queries will help
us
>>>>>> define a cleaner Store interface.
>>>>>>
>>>>>
>>>>> I'm always in favor of named queries.
>>>>> An other point about them that I haven't explain in previous threads
>> (I
>>>>> think) is that with named queries, it is possible to modify queries
>>>>> externally with xml files so if with a DB we have some performance
>>> issues,
>>>>> it will be possible to override queries by a modified JPQL query or
>> a
>>> native
>>>>> query.
>>>>>
>>>> How do you see the refactored ContinuumStore interface using Named
>>>> Queries? I suspect it will be just as verbose again.
>>> I don't want to see a new time a big class for the store part. it must
>> be
>>> splitted in few domains.
>>> All named queries related to Project would be defined in the Project
>> class,
>>> all named queries related to ProjectGroup would be defined in the
>>> ProjectGroup class...
>>>
>>> And we can add some more classes for particular results that aren't
>> entities
>>> objects (we won't have a lot)
>>>
>>> With this, all concerns are separated and linked to a specific entity.
>> Easy
>>> to code, easy to read, easy to understand. It's my opinion.
>>>
>>>> Sorry, still not convinced ;-)
>>> I hope you are now ;-)
>>>
>>> Emmanuel
>>>>
>>>> Rahul
>>>>
>>>
>

Mime
View raw message