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 < [email protected]> 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 <[email protected]> wrote: > >> On Wed, Sep 21, 2011 at 19:33, Dan Allen <[email protected]> wrote: >> >>> On Wed, Sep 21, 2011 at 18:30, Stuart Douglas < >>> [email protected]> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
