Re: 3T Relationships [are done]

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Sep 16 2005 - 09:50:37 EDT

  • Next message: jira-norepl..bjectstyle.org: "[OS-JIRA] Created: (CAY-378) Importing EO Model doesn't import the attribute if the class property isn't set."

    I wouldn't worry about it much if it only were for reporting. But I
    think I have a quite common use case. The project I am currently
    working on has end user tools written in Swing (and use client
    objects), but all the admin tools are implemented as web applications
    (and use server objects).

    And yes the code below is used for display, but both client and
    server objects need it. When almost every entity has 3-4 methods like
    that, copy/paste code reuse becomes a pain. I can handle it in my
    project, just create some common unit tests or something, but I think
    this leaves a hole in the overall multi tier design...

    Oh well, I guess there are always tradeoffs with any complex
    technology...

    Andrus

    On Sep 15, 2005, at 7:29 PM, Marek Wawrzyczny wrote:

    > On Fri, 16 Sep 2005 06:47, Tore Halset wrote:
    >
    >> On Sep 15, 2005, at 22:30, Andrus Adamchik wrote:
    >>
    >>> What I am still unclear is a very simple case below. Consider this
    >>> method called from UI (web or Swing), not on commit:
    >>>
    >>> public String getUrl() {
    >>> return getPart1() + getPart2() + getPart3();
    >>> }
    >>>
    >>> I am trying to avoid duplication of this code between client and
    >>> server classes. I guess inheritance of server objects from client
    >>> objects would be an option...
    >>>
    >>
    >> Ok, I see. The server class could contain some logic that should not
    >> be exposed on the client. Like dependant on other jars, or some
    >> secret biz logic. So inheritance of server classes are not always a
    >> good option.
    >>
    >> I think code duplication is ok in that case :/
    >>
    >
    > I think code duplication is ok.
    >
    > What the above function describes is a way to display data. As
    > such, the code
    > doesn't even necessarily make sense to exist on the server since it
    > (in a
    > server/client situation) would not typically deal with displaying
    > any data.
    >
    > The exception here could be running/creating reports, exports and
    > printing. I
    > would still argue that this sort of functionality should be
    > implemented
    > client side.
    >
    > --
    > -
    > Marek W
    >
    > --
    > 2b | !2b
    > Send instant messages to your online friends http://
    > au.messenger.yahoo.com
    >
    >



    This archive was generated by hypermail 2.0.0 : Fri Sep 16 2005 - 09:50:39 EDT