Hi guys,<div><br></div><div>I see some problems on using extends for this approach:</div><div><br></div><div>1) I tend to follow the principle composition over inheritance aka "<span class="Apple-style-span" style="font-family: sans-serif; font-size: 13px; line-height: 19px; background-color: rgb(255, 255, 255); ">Composite Reuse Principle",</span></div>
<div>The application design is more flexible when you're not highly tied with "extends".</div><div>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.</div>
<div><br></div><div>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. </div>
<div>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.</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br><br><div class="gmail_quote">On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Sep 21, 2011 at 19:33, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Sep 21, 2011 at 18:30, Stuart Douglas <span dir="ltr"><<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>I don't really like that idea, as it means that forge then becomes part of your build process. </div></div></blockquote><div><br></div></div><div>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.</div>
</div></blockquote><div><br></div></div><div>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.</div>
<div><br></div><font color="#888888"><div>-Dan</div><div> </div></font></div><div><div></div><div class="h5">-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br>
<br><div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br>
<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>
</div></div><br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><br></div>