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

[José Rodolfo Freitas]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/0040f39d/attachment-0001.html