[seam-dev] SAF (aka Entity Framework) idea in Seam 3

Wed Sep 21 23:30:18 EDT 2011

I actually have to agree with Jose. (Don't worry, you are a smart guy, and
we are not that smart :)

The EntityManager wrapper pattern in Forge is OK, but it's not a very
strongly architected solution. I used it because it was easy, and I tend to
think that solutions like it are done simply because "even though it smells,
nobody has a better idea of what to eat." In fact, the only reason Forge
uses "extends" via PersistenceUtil is because I need to inject a properly
scoped EntityManager into *something* in order to make sure the correct one
is used. That being said, perhaps one solution is to offer multiple
producers for EntityManagers:

   - The stateless EntityManager
   - The request / conversation / session scoped EntityManagers
   - The application-scoped entity manager

I am also actually very much in favor of Jason's idea:
https://issues.jboss.org/browse/SEAMFORGE-280 combined, or paired with
something like http://code.google.com/p/lambico/ (More the GORM-style
approach) for simpler queries. DAOs are so 2005, and nobody liked them then.

These objects could be exposed via @Named in EL, and of course be made
injectable.

There are also other approaches, like "Active Record," but in my opinion,
the EntityManager poses a bit of a problem: It requires that it must already
know about the entity. And in my experience that is an inherently difficult
problem to overcome when attempting to build truly stateless applications -
resulting in duplicate calls to the database to fetch data that you already
have (just to sync things up.) While this is good for things like
transactionality, it is bad for performance, but before I get too far off
topic here, I'm just going to stop :) In a sense, we are fighting against
JPA combined with a Strongly Typed language. I think that the lambico
approach (annotating interfaces, like what Spring did - yep I said it) is
actually the best approach I've seen in a long time.

When you can't beat 'em, join 'em. (Then beat 'em)

My 2 cents,
~Lincoln

On Wed, Sep 21, 2011 at 11:04 PM, José Rodolfo Freitas <
joserodolfo.freitas at gmail.com> wrote:

> And if something was written in an unclear English, I'd like to remind you
> that those were my last minutes of a long day.
>
>
> On Wed, Sep 21, 2011 at 11:59 PM, José Rodolfo Freitas <
> joserodolfo.freitas at gmail.com> wrote:
>
>> Hi guys,
>>
>> I see some problems on using extends for this approach:
>>
>> 1) I tend to follow the principle composition over inheritance aka "Composite
>> Reuse Principle",
>> The application design is more flexible when you're not highly tied with
>> "extends".
>> And since we already have something that kinda do some of the boilerplate
>> code we're talking about, the entityManager, AND it works with a simple
>> association (injection), I think that a better way to extend CRUD
>> functionalities would be to wrap the EM up, add what we think is needed and
>> inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're
>> going to create a new class that mostly will delegate calls to
>> entityManager.
>>
>> 2) to keep code simple, I think that organizing classes by use cases (like
>> booking for instance) is a really good approach, instead of having a
>> PersonController, PersonService, PersonDAO and PersonEntity, that
>> accumulates all kind of code related to Person use cases. Very often those
>> classes become bloated.
>> Having a package that handle its own use case, HiringPerson, for instance
>> (dunno if it's a good example, though), seems more natural. The code is more
>> atomic and when maintaining code, you're not swimming at a bunch of code not
>> related to your case, and this in fact gives more value to reuse and code
>> design. than always using the same structure over and over again.
>> IMHO, If we create a genericDAO<Entity T> to be extended, I'm afraid that
>> will encourage that kind of approach (PersonController, PService, PDAO and
>> etc). If we do a more flexible way, we can easier work with both ways as
>> one'd wish.
>>
>> 3) when we force the use of extends to do something that could be done
>> with composition, we're killing other design possibilities. Frequently, we
>> have to do an extends of an extends to workaround that. I mean if we have a
>> class A  that extends G and by design it seems logical that A should extends
>> B. People workaround that making B extending G (even though sometimes B has
>> nothing to do with G) so A can use both classes as parents.
>>
>> I really feel intimidated disagreeing with people that know so much like
>> you guys, but I still think it's worth more discussion around that.
>>
>>
>> On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>>
>>> On Wed, Sep 21, 2011 at 19:33, Dan Allen <dan.j.allen at gmail.com> wrote:
>>>
>>>> On Wed, Sep 21, 2011 at 18:30, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com> wrote:
>>>>
>>>>> I don't really like that idea, as it means that forge then becomes part
>>>>> of your build process.
>>>>>
>>>>
>>>> Ah, I was suggesting that you add the annotation, then use Forge as a
>>>> utility once to create the dao classes. Sort of forward engineering.
>>>>
>>>
>>> And the reason that's beneficial is because it tells forge which entities
>>> should have a dao...instead of it just blindly doing it for all entities.
>>> This could also be a hint as to which UI pages to create.
>>>
>>> -Dan
>>>
>>> --
>>> Dan Allen
>>> Principal Software Engineer, Red Hat | Author of Seam in Action
>>> Registered Linux User #231597
>>>
>>> http://www.google.com/profiles/dan.j.allen#about
>>> http://mojavelinux.com
>>> http://mojavelinux.com/seaminaction
>>>
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>

-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/60a96653/attachment-0001.html 