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

Tue Sep 27 12:59:43 EDT 2011

good point.
Naming was not my focus here though, it was just a quick example.

On Tue, Sep 27, 2011 at 1:55 PM, Max Rydahl Andersen <
max.andersen at redhat.com> wrote:

> don't use save or saveOrUpdate - those are old Hibernate API methods which
> doesn't do the same as what update/persist does.
>
> The semantics are similar but different enough to not overload the words
> since it requires a different usage of the API.
>
> My 2 cents ;)
>
> /max
>
> On Sep 27, 2011, at 17:57, Jason Porter wrote:
>
> > I prefer the idea that there's a class that manages one instance and
> that's all it does, and another object (or objects) to handle collections of
> those objects. I think separating them out makes for better reusability. If
> we'd like to have a save method I'm okay with that, but don't really see the
> need.
> >
> > Sent from my iPhone
> >
> > On Sep 27, 2011, at 7:32, José Rodolfo Freitas <
> joserodolfo.freitas at gmail.com> wrote:
> >
> >> Sorry for not being able to post my gist. After writting some
> "sketches", I realized that I don't have it very clear in my mind yet.
> >>
> >> just to move from zero I posted something:
> >>
> >> https://gist.github.com/1245041
> >>
> >> It's a really simple example on how we could avoid inheritance,  but
> it's not contemplating a lot of needed features,
> >> so I'm not even near to be convinced with that gist.
> >>
> >> btw, the @AutoHome approach seems very nice.
> >>
> >>
> >> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <dan.j.allen at gmail.com>
> wrote:
> >> Exactly. flush() has a specific purpose and really doesn't belong in
> boilerplate code.
> >>
> >> - Dan Allen
> >>
> >> Sent from my Android-powered phone:
> >> An open platform for carriers, consumers and developers
> >>
> >> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" <
> max.andersen at redhat.com> wrote:
> >> > just one comment:
> >> >
> >> > Calling .flush() on every alteration really should not be promoted as
> a good practice.
> >> >
> >> > /max
> >> >
> >> > On Sep 22, 2011, at 24:22, Dan Allen wrote:
> >> >
> >> >> Here's some additional feedback I received from a community member a
> while back...to merge it into this thread.
> >> >>
> >> >> (begin feedback)
> >> >>
> >> >> ...from being burned from 3 seam based customers with apps and
> maintenance. The "Home" or any other name should be just be put into a grave
> and slowly cast away to sea ;). It is too heavy and complicated and just
> about anything inherited (extends) truly causes heartache[Favor Composition
> over inheritance: Effective Java]. The current seam home has a few super
> classes above the home and when you try to unit test it (the standard
> definition of unit-testing including isolation) you get the "No Active
> Application Context Found (if I remember it right). That happens because it
> is tightly coupled with the application. But not to be hard on Home, I do
> realize the history of the home object and know it was developed when EL had
> no parameters. So I have learned a lot since then and I here are some things
> that I can impart to Seam 3.
> >> >>
> >> >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major"
> entity, see below. I have really stewed over this over months and months,
> and the "Home" of "ServiceBean" should be kept small, focused, reusable,
> tested and untouched. It's only task is to update, persist, possibly remove,
> or some other functions that are required. In my example below I have custom
> close action. Notice also that although these beans are stateful that
> doesn't mean everything should be, so in these methods I have the parameter
> of what is being needed to be updated, and not a field. In other words I
> don't have @In private Job job, I opted for public boolean update(job).
> Mostly because, again, I want to make this service bean reusable so whether
> I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of
> job I need to work on I only need one jobServiceBean to cater to all my
> jobs, in whatever conversation I am using. I also fire events from here if I
> need to do that. !
> >> > After this is tested, and what I need I usually don't touch it
> anymore. If I need to enhance I either use a decorator pattern around it, or
> enhance it in an @Observer. I'll email about that later.
> >> >>
> >> >> @Name("jobServiceBean")
> >> >> @Scope(ScopeType.CONVERSATION)
> >> >> public class JobServiceBean implements JobService {
> >> >> private EntityManager entityManager;
> >> >> private StatusMessages statusMessages;
> >> >>
> >> >> @In
> >> >> public void setEntityManager(EntityManager entityManager) {
> >> >> this.entityManager = entityManager;
> >> >> }
> >> >>
> >> >> @In
> >> >> public void setStatusMessages(StatusMessages statusMessages) {
> >> >> this.statusMessages = statusMessages;
> >> >> }
> >> >>
> >> >> public boolean update(Job job) {
> >> >> this.entityManager.flush();
> >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
> updated job {0}", job.getName());
> >> >> return true;
> >> >> }
> >> >>
> >> >> public boolean close(Job job) {
> >> >> job.setJobStatus(JobStatus.CLOSED);
> >> >> this.entityManager.flush();
> >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
> closed job {0}", job.getName());
> >> >> return true;
> >> >> }
> >> >> }
> >> >>
> >> >> 2. One thing you may have noticed from above that there is no
> 'instance' field with corresponding getters or setters like the old 'Home'.
> So the ServiceBean in my case is not a full crud, but CUD + your own
> business methods. That's because that too should be decoupled because we
> never know the source of the object is. Is the object created from a
> factory? from a copy? is it a mapped component, a managed component?
> Creation of objects or loading of objects, or the manufacturing of objects
> from factories should be separate from the "home" or in my case the
> "ServiceBean".
> >> >>
> >> >> (end feedback)
> >> >>
> >> >> --
> >> >> 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
> >> >>
> >> >> _______________________________________________
> >> >> forge-dev mailing list
> >> >> forge-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> > /max
> >> > http://about.me/maxandersen
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > forge-dev mailing list
> >> > forge-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >>
> >> _______________________________________________
> >> 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
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110927/c3c34c47/attachment.html 