1 2 Previous Next 19 Replies Latest reply on Jan 2, 2007 9:27 PM by guanwh Go to original post
      • 15. Re: Avoiding the DRY Principle with beans
        norman.richards Dec 24, 2006 4:26 PM (in response to dhinojosa)

        This question does not appear to be related to the topic of this thread.

          • Actions
        • 16. Re: Avoiding the DRY Principle with beans
          jpviragine
          jpviragine Dec 24, 2006 6:14 PM (in response to dhinojosa)

          Fábio,

          UserService is the local interface for the UserManager?

          So, try:

          interface UserService extends BusinessService {
 login();
}



          P.S. Sorry about my English. :-)

          Cheers,

          João Paulo

            • Actions
          • 17. Re: Avoiding the DRY Principle with beans
            norman.richards Dec 24, 2006 7:07 PM (in response to dhinojosa)

            Please create a new topic for this. (and if the original poster does, maybe he will show where "myMethod" is supposed to be implemented, since that's what the error is about)

              • Actions
            • 18. Re: Avoiding the DRY Principle with beans
              fabio.ita04 Dec 24, 2006 10:05 PM (in response to dhinojosa)

              First of all, I think this post is closelly related with original topic: build session beans that encapsulates commom business logic, taking advantage of Seam annotations (inheritance of annotaded members: @in, @out, @datamodel, @datamodelselection, @begin, @end, @destroy, etc).

              Please tell me exatly the reasons you think the topics aren't related, so I'll be convinced to create a new topic.

              The code I sent is just a draft based on original code. The implementations are ok, and what I see it's happening is problems with EJB proxying.

              In the following codes, *Service refers to interfaces, and *Manager refers to Stateful Session Bean classes.

              When I write single (direct) hierarchies

              BusinessManager implements BusinessService

              everything runs allright.

              But I'll have to write interfaces UserService, CompanyService, EmployeeService, ContactService, etc... that closelly shares the same structure (methods save(), search(), select(), destroy(), etc...).

              And worse: the implementations (BusinessManager) are identical in the vast majority of cases. Just in few cases a subclass will need to override the default BusinessManager behavior.

              So ideally, the best thing to do would be: 

              interface BusinessService (common Service method declarations)

BusinessManager implements BusinessService (default implementations)

interface UserService extends BusinessService (declares User related methods)

UserManager extends BusinessManager implements UserService
(UserService implementations and some BusinessManager overriding)


              But in this case, only UserService methods are proxied in the UserManager objects (exception occurs when trying to invoke BusinessManager methods - the exception says the UserManager proxy don't have the related BusinessManager / BusinessService methods).

              If needed, in the next reply I send the UserManager code I've mentionated.

              Thanx
              Fábio.

                • Actions
              • 19. Re: Avoiding the DRY Principle with beans
                guanwh
                guanwh Jan 2, 2007 9:27 PM (in response to dhinojosa)

                guys, you do not need repeat the work.Seam already has EntityHome and EntityQuery which exactly do the same thing you want.
                Correct me if I am wrong.

                Thanks

                  • Actions
                1 2 Previous Next