Announcement Announcement Module
Collapse
No announcement yet.
Any negative experience? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Ben Alex
    5. The domain model matters are not "swept under the carpet" at all.
    Then they are in a basement, inside a locked filing cabinet, in a disused lavatory with a sign saying "Beware of the leopard” on the door.

    I've read through the 640-page volume Professional Java Development With the Spring Framework, and found no serious discussion of the topic.

    Spring developers in these forums have suggested anemic domain solutions to these questions in the past, clearly prioritizing needs of the framework over design concerns. The only time I have seen a Spring developer give the matter serious concern in these forums is when http://forum.springframework.org/showthread.php?t=9846. That code sits outside of the packaged releases, and support requests have been deferred until release 1.4 of Spring.

    Originally posted by Ben Alex
    The reality is that domain objects need to have certain concessions made to permit their reuse in ORM tools and MVC forms.
    You may need to be more specific here. The challenges that I have encountered in implementing my domain objects are issues with Spring, not Hibernate.

    Originally posted by Ben Alex
    If you want to see production-quality services and domain layers that reuse these concerns, check out the Acegi Security Domain subproject (in CVS). It is a simple few classes that show you how to do it properly.
    I am interested, can you point to where these classes are located? I am rummaging about in samples/quickstart... right now. This really gets back to my point about the lavatory and the leopard.

    There may be a terrific set of best practices out there for dealing with domain issues in Spring, but my point is that the Spring team has not been effective in publically articulating them if they do exist. I think from reviewing the forum activity it's kind of difficult to argue that point.

    Originally posted by Ben Alex
    We welcome constructive suggestions on how to improve Spring.
    I hope you are finding me constructive. I have a lot of respect for the project.
    Last edited by robyn; May 14th, 2006, 08:42 PM.

    Comment


    • #17
      Originally posted by Ben Alex
      The MVC framework is also very high. If you have specific concerns with the MVC approach, why not raise them in the MVC forum so the rationale can be explained?
      I might do that, but there seem to be some core philosophical differences, and until now I've been happier to 'agree to disagree' rather than get into a big debate over it when there are clearly some happy users.

      Originally posted by Ben Alex
      To assert that Spring quality is inconsistent should at the very least be justified by reference to specific concerns.
      Very well, as you wish.

      Spring MVC promotes itself as providing better separation between Model, View, and Controller, but it feels to me like tighter coupling. Spring MVC wants me to put view names into my controller. Spring MVC wants me to put form names into my .JSP files. These tight couplings don't exist in Struts, and it makes a lot of difference to me.

      When I search the Web forum for questions on chaining controllers (not discussed in Professional Java Development With the Spring Framework), Spring developers reply that 'for advanced navigation needs, you need to look at Spring Web Flow'. Huh?

      On page 504 of Professional Java Development With the Spring Framework, the developers tell us that "we explicitly decided not to include a tag library for generating markup" in .JSP files.

      So, instead of:

      Code:
      <html&#58;text property="name"/>
      we are given:

      Code:
      <spring&#58;bind path="command.name">
        <input type="text" name="$&#123;status.expression" value="$&#123;status.displayValue&#125;">
      </spring&#58;bind>
      Incredibly, we are given the rationale that it is easier for HTML developers to work with the second example than the first.

      Thankfully, it looks like a JSP 2.0 tag library is coming in Spring 1.3, representing an about face from their explicit design decision not to include such a library.

      In general, the decisions made in Spring MVC make less sense to me than those in Spring Core. But I recognize that this is a personal preference, and that smart people disagree with me.

      Comment


      • #18
        Well, I'm a new Spring user, however as a new user perhaps I can bring a different perspective to the discussion. I'm also, going to try to be as constructive as I can here, so I hope the Spring developers don't get too upset with me . That disclaimer stated, here are some of aspects of Spring that have given me some pause:

        1. The current bean configuration file methods seem problematic for a few reasons:

        - Scalability – These files must turn into complete nightmares in projects which require large amounts of beans (i.e. controllers/validators/forms/DAOs etc.). There must be a more hierarchical and well defined approach to configuring these things (e.g. DAOs in once place, controllers in another etc). I realize you can arbitrarily segregate things on your own, however this “freedom” merely compounds the problem as everyone has their own way of doing something that the framework should (IMHO) define in the first place and more importantly enforce (in real life groups of programmers may not necessarily follow the arbitrary configuration file method).

        - Clarity – Looking at these XML files as a new user, I was assaulted by a lot of redundant information, obviously this has more to do with XML than Spring. However, I think XML has its place, but clearly this cannot be the best way to accomplish the “wiring” (injection) process that Spring is intended to do. I suspect a domain specific scripting language as already suggested would go along way to bringing more clarity to the “wiring” process.

        2. The so called “Anemic anti-pattern”
        - I’m going to have to second the opinions of the others in this thread, and say the “compromises” that must be made to a given domain model to utilize spring are somewhat concerning. A wise man one said in a well written book:

        “It's vital that we use J2EE to implement OO designs, rather than let our use of J2EE dictate object design.”

        The fellow was Rod Johnson, one of the founders of Spring. As I sit here now, I find myself thinking how I can design my OO domain so I can utilize Spring, instead of designing OO domain and simply utilizing Spring to wire it all together. The very fact that I (and presumably many others) have to think this way says that Spring clearly has too much influence over the OO design, and thus goes against the principle Rod once and may still believe in.

        Illustrative Example: Say you were designing a object to represent a virtual Horse, in a good OO design the Horse would have a “gallop” method, but in the Spring world you’d make a HorseGallopService and send your anemic "Horse" objects there to get them to gallop . Clearly an odd state of affairs.

        To those that dispute/refute this, it would be nice to see some Spring app examples similar to petclinic and jpetstore (though with a tad more business logic) which are implemented in as close to a true OO design as humanly possible. i.e. thin out the "service" layer as much as possible and put as much business logic back in the domain objects as possible.

        My solution for this? ....gosh I can't really think of any , though I think it is important to recognize any limitations, properly document them, and give developers means or "best practices" to minimize their impact.

        Anyhow, I'm going to continue plugging along and learning Spring. However I'm fighting with the notion of having to use a compromised OO design methodology in order to reap the benefits of Spring.


        Richard...

        Comment


        • #19
          I find the configuration files to quickly become big and unreadable.
          We found this to be an issue as well, but made it pretty much a non-issue by:

          1. Breaking config files into areas, e.g. single controllers.xml file that imports all other controller-*.xml files. We have >40 .xml files and it's now pretty easy to at least guess the correct file for some bean you're looking for.

          2. Use XmlBuddy in Eclipse, and use the outline view. This lets you quickly find a bean within an .xml file.

          Suggested improvements ...

          It would be cool if someone could create an Eclipse plugin that allowed hotkey'ing of a class, which then opened the corresponding Spring .xml file and selected that bean.

          e.g. Select MyClass at the top of the .java file, hit Ctrl-Alt-S (for Spring) or something, and then XmlBuddy editor opens showing the <bean ...> definition that references that class.

          I've built a few simple plugins but i've got absolutely no idea how to hook into the Java editor part of Spring.

          Comment


          • #20
            Originally posted by gmatthews
            Suggested improvements ...

            It would be cool if someone could create an Eclipse plugin that allowed hotkey'ing of a class, which then opened the corresponding Spring .xml file and selected that bean.
            I don't think Spring IDE for Eclipse does that yet. But, perhaps the new Spring IDE with SpringXMLEditor does; I haven't tried the new stuff yet. That capability is essential.

            Comment


            • #21
              Jacn is my answer

              I create Jacn (http://jacn.sourceforge.net) just to alleviate the XML pain. Rather than creaing a new domain language, I hijack Java for DI programming, so it is immeidately IDE friendly.

              Here is the Jacn version of the configuration sample:

              Code:
              public class Jacn_scratch extends AbstractJacnConfigFile &#123;
              	static ScheduledThreadPoolExecutorFactoryBean indexUpdaterScheduler;
              	
              	public void wire&#40;&#41; throws Exception &#123;
              		indexUpdaterScheduler.setThreadFactory&#40;new StdThreadFactory&#40;2, indexUpdater&#41;&#41;; 
              			
              		ScheduledWithFixedDelayRunnable fdr = new ScheduledWithFixedDelayRunnable&#40;&#41;; &#123;
              			MethodInvokeSequenceRunnable misr = new MethodInvokeSequenceRunnable&#40;&#41;; &#123;  
              				MethodInvoker mi1= new MethodInvoker&#40;&#41;; &#123;
              					mi1.setTargetObject&#40;indexUpdater_image&#41;;
              					mi1.setTargetMethod&#40;"process"&#41;;
              				&#125;
              				MethodInvoker mi2= new MethodInvoker&#40;&#41;; &#123;
              					mi1.setTargetObject&#40;indexReaderProviderService_image&#41;;
              					mi1.setTargetMethod&#40;"refresh"&#41;;
              				&#125;
              				MethodInvoker mi3= new MethodInvoker&#40;&#41;; &#123;
              					mi1.setTargetObject&#40;indexUpdater_movie&#41;;
              					mi1.setTargetMethod&#40;"process"&#41;;
              				&#125;
              				
              				Object invokers = new Object&#91;&#93; &#123;mi1, mi2, mi3&#125;;
              				
              				misr.setMethodInvokerList&#40;&#40;List&#41;invokers&#41;;
              			&#125;
              			fdr.setRunnable&#40;misr&#41;;
              			fdr.setInitialDelay&#40;5&#41;;
              			fdr.setDelay&#40;30&#41;;
              			fdr.setTimeUnit&#40;SECONDS&#41;;
              		&#125;
              		// another one omiited
              		Object list = new Object&#91;&#93; &#123;fdr&#125;;
              		indexUpdaterScheduler.setScheduledWithFixedDelayRunnables&#40;&#40;List&#41;list&#41;;
              	&#125;
              &#125;
              Jacn uses bytecode techniques for extracting object dependencies and is very simple to deploy (simpler than using XML);

              Jacn is at versoin 0.3 and I'm using it in a big project with ~200 managed beans.

              Cheers

              Bing Ran

              Comment


              • #22
                Originally posted by cepage
                Originally posted by Ben Alex
                If you want to see production-quality services and domain layers that reuse these concerns, check out the Acegi Security Domain subproject (in CVS). It is a simple few classes that show you how to do it properly.
                I am interested, can you point to where these classes are located?
                Ben regrettably lacks either the time or interest to continue this discussion. The only relevant example I can find in the Acegi subproject is Acegi's approach to Domain Object Instance Security.

                The approach here is to identify domain object methods that require access to application services, and isolate access to those methods to a predefined stateless service (in this case, an associated Manager service). Then the code that actually accesses the service is moved out of the domain object and into the Manager class, or into a MethodSecurityInterceptor.

                This is clearly a blatant promotion of the Anemic Domain Model antipattern that we have discussed in this thread. It seems almost disingenuous to promote this as a solution to the problem thay many users have raised here.

                Comment


                • #23
                  When I search the Web forum for questions on chaining controllers (not discussed in Professional Java Development With the Spring Framework), Spring developers reply that 'for advanced navigation needs, you need to look at Spring Web Flow'. Huh?
                  Corby,

                  Just to address this one point quickly.

                  If you look at the Spring MVC Controller interface, you´ll see Controller chaining really doesnt make sense. A controller is expected to broker a request and return a logical pointer to a view provisioned with all renderable model data. There is no notion of a ModelAndView that gets passed around as part of a chain.

                  So the answer here, though vague, was a good general recommendation. The Spring MVC Controller interface is simply not designed for this.

                  Spring Web Flow, on the other hand, is integrated with Spring MVC (see FlowController in the webflow.mvc package) and has a much more elaborate action model invokable from within an architecture based on a finite state machine, with the capability to chain command logic. So certainly, one of the reasons SWF exists is to serve this chaining (CoR) need, and we consider use of a FlowController to delegate to a webflow to achieve this a good solution. You could also have a MVC Controller delegate to a more generic CoR framework, like commons-chain, but you will find SWF more capable.

                  So to give you an example of what SWF can do, take the following code snippet:

                  Code:
                  public class MySimpleFlowBuilder extends AbstractFlowBuilder &#123;
                      public String flowId&#40;&#41; &#123;
                          return "simpleFlow";     
                      &#125;
                  
                      public void buildStates&#40;&#41; &#123;
                          addEndState&#40;"doSomeStuffThenDisplayAPage", "thePageName"&#41;.setEntryAction&#40;
                              new CompositeAction&#40;new Action&#91;&#93; &#123;
                              method&#40;"method1", action&#40;"myFlowAction"&#41;&#41;,
                              method&#40;"method2", action&#40;"myFlowAction"&#41;&#41;,
                              method&#40;"method3¨, action&#40;"myFlowAction"&#41; &#125;&#41;&#41;;
                      &#125;
                  &#125;
                  A very simple flow definition, that when invoked (by hitting the url /flowcontroller.htm?_flowId=simpleFlow) will enter the "doSomeStuffThenDisplayAPage" state, execute those action methods in an ordered chain ("method1", "method2", "method3"), and request the rendering of "aPage" which is resolved to a renderable template using a standard Spring MVC ViewResolver.

                  You gain additional benefits here in that your action logic is now decoupled from the underlying HTTP API, so it can be run in a Portlet environment, for example. In addition, with the upcoming WebFlow RC1, you can invoke command logic encapsulated directly within standard POJOs with no dependencies on webflow at all. In this case, you´re typically telling webflow to invoke your business logic directly, and webflow handles the necessary controller glue.

                  So while this is a very trivial flow that lives only for a single request (is essentially stateless) & does nothing more than execute some logic in a chain and display a results page, it shows some of what webflow is capable of, invokable directly from Spring MVC (or Struts for that matter).

                  An aside: if you dont like looking up your actions by name like in the flow definition above, and instead prefer lookup by type or by direct reference, you can do that as well.

                  Keith

                  Comment


                  • #24
                    Thanks, Keith. I will take a closer look at SWF as it nears final release.

                    Comment


                    • #25
                      Re: Any negative experience?

                      Originally posted by hucmuc
                      Originally posted by cepage
                      Originally posted by ivom2gi
                      Before jumping into the next, ten times bigger project I would like to know about IRL limitations faced by developers using spring. I have read different books, manuals and APIs so I should be aware of all the theoretical aspects, but still ... it cannot be as good as it seems ...
                      I'm very happy with Spring, but there are two big problems I run into.

                      First, Spring does not have a consistent philosophy for dealing with stateful objects, domain objects in particular. The main Spring guys tend to promote the Anemic Domain Model antipattern as a solution to this, which is just sweeping the problem under the rug.

                      You can get a sense from this http://forum.springframework.org/showthread.php?t=15294 as to how much confusion there exists on how to properly manage rich domain objects within a Spring application. I have not yet encountered any unsolvable problems in this area, but there tends to be a lot of wailing and gnashing of teeth in the absence of best practices.
                      I too have not been satisfied with how the Spring developers try to explain the philosophy on stateful objects. If you look at the spring code it is conveniently swept under the rug. For example, the BeanWrapper class. The spring source code always instantiates with a BeanWrapperImpl class. Why isn't this injected? I wish it were since I could implement my own version and could write an ant task to validate configuration files.

                      Since I've been using Spring, I sometimes change the way I implement things. Instead of using stateful objects, I would use singletons and pass in variables as arguments. Why? It is much easier to inject singleton based objects than prototypes.

                      There's something missing here and I can't find a consistent and explainable solution.

                      Dino
                      I personally agree with you.
                      Our company is running away from Stateful EJB and we are only using singletons passing them variables as arguments.
                      very simple and understandable and very fast (using Spring or not)

                      Leo
                      Last edited by robyn; May 14th, 2006, 08:18 PM.

                      Comment


                      • #26
                        Originally posted by cepage
                        Originally posted by cepage
                        Originally posted by Ben Alex
                        If you want to see production-quality services and domain layers that reuse these concerns, check out the Acegi Security Domain subproject (in CVS). It is a simple few classes that show you how to do it properly.
                        I am interested, can you point to where these classes are located?
                        Ben regrettably lacks either the time or interest to continue this discussion. The only relevant example I can find in the Acegi subproject is Acegi's approach to Domain Object Instance Security.

                        The approach here is to identify domain object methods that require access to application services, and isolate access to those methods to a predefined stateless service (in this case, an associated Manager service). Then the code that actually accesses the service is moved out of the domain object and into the Manager class, or into a MethodSecurityInterceptor.

                        This is clearly a blatant promotion of the Anemic Domain Model antipattern that we have discussed in this thread. It seems almost disingenuous to promote this as a solution to the problem thay many users have raised here.
                        I apologise to the Spring community for not replying sooner. As suggested by Corby, I have been extremely busy. I certainly have an interest in the subject.

                        The Domain subproject aims to separate functionality into:

                        - DOs that can be used in persistence and form backing objects.

                        - DOs that shift validation responsibilities to a Validator.

                        - Manager and DAO objects that work with a DO, but the DO uses associations to avoid needing to have a separate Manager and DAO for each and every DO.

                        - You override methods on the Manager to coordinate workflow.

                        - Because each DO uses associations, logic can be added to the domain object itself. So your Order DO can manage the totals for its associated LineItems.

                        I have used the Domain Subproject in several projects, and had excellent results. I am aware of several others who have also used it and materially reduced their lines of code. In the end your DO model is 100% Java, totally separated from Spring, easily unit tested, and reflecting as much functionality as is reasonably possible to put into the DO (ie functionality that is not coordinating functionality, which belongs in a services layer method).

                        The anemic domain model is having DOs with nothing more than JavaBean getters and setters. The Acegi Security Domain subproject does not promote or encourage this.

                        Comment


                        • #27
                          Originally posted by Ben Alex
                          - Because each DO uses associations, logic can be added to the domain object itself. So your Order DO can manage the totals for its associated LineItems.
                          We are in agreement here. Our primary point of disagreement is whether domain objects should ever be allowed to access application services, not just other domain collaborators.

                          This is over a year old, so let me know if your view has changed, but in http://forum.springframework.org/showthread.php?t=9846 you state your position pretty clearly:

                          But it seems easier to me to just stick with what Spring makes easy... If you need a singleton collaborator... it's probably application logic. [and doesn't belong in a domain object]

                          Some simple examples. When an operation is performed on a domain object that will trigger a change in workflow state, I like for my domain object to directly message my OSWorkflow service to effect the change. When a delete operation needs to be performed on a single domain object, I like the domain object to be issued the delete operation, and allow him to in turn pass the message onto the DAO.

                          I am not saying there is one right answer here. As you have mentioned, the approach you have taken has worked for you on successful projects. But right now, Spring only supports your approach, not mine.

                          Thankfully, that will change. As Rod has noted elsewhere, Adrian's AspectJ 5 integration will make it easy to inject collaborating services into domain objects, or any other stateful objects for that matter. Each of us will have the ability to adopt the architectural approach that we are most comfortable with.
                          Last edited by robyn; May 14th, 2006, 08:03 PM.

                          Comment


                          • #28
                            Acegi Security Domain subproject (in CVS)

                            Originally posted by Ben Alex
                            5. The domain model matters are not "swept under the carpet" at all. In the Spring Training courses we advocate first focusing on your domain objects and their relationship with service layer interfaces, only dealing with implementation issues like Spring and concrete implementations after those preliminary steps have been completed. The reality is that domain objects need to have certain concessions made to permit their reuse in ORM tools and MVC forms. If you want to see production-quality services and domain layers that reuse these concerns, check out the Acegi Security Domain subproject (in CVS). It is a simple few classes that show you how to do it properly. It's not part of core Spring or even core Acegi Security because developers will typically introduce similar classes and interfaces within their own application if appropriate. Feel free to cut 'n' copy it into your codebase and customise further.
                            Here is a quick link to the Acegi Security source tree in CVS
                            http://cvs.sourceforge.net/viewcvs.py/acegisecurity

                            Navigate to the domain folder under the link above. HTH.

                            -Eric

                            Comment


                            • #29
                              Originally posted by Alarmnummer
                              If I remove the XML syntax and introduce a domain language, I can guarantee that the config files will be a lot shorter.
                              I doubt it. Even in the example you posted, while the domain language version is shorter in the sense of number of lines, it's not materially simpler. The domain language in the example is essentially XML in shorthand - with the full closing tags replaced with single closing brackets, attribute names replaced with a more positional-based syntax, etc. The complexity of definitions written in the domain language is in the same order of magnitude as that of in XML.

                              Comment


                              • #30
                                Originally posted by manifoldronin
                                Originally posted by Alarmnummer
                                If I remove the XML syntax and introduce a domain language, I can guarantee that the config files will be a lot shorter.
                                I doubt it. Even in the example you posted, while the domain language version is shorter in the sense of number of lines, it's not materially simpler.
                                That is correct and it was never meant to make it simpeler, just less verbose.

                                Would you like to program java in a XML based syntax? You write the same:
                                Code:
                                <ifstatement>
                                    <condition>
                                          <varable>a</variable>
                                          <operator>==</operator>  
                                          <constant>10</constant>
                                    </condition>
                                    <then>
                                       ....
                                    </then>
                                </ifstatement>
                                Or do you like the easier-on-the-eyes-syntax:

                                Code:
                                if&#40;a==10&#41;&#123;
                                ...
                                &#125;
                                Semantically they are both the same.. just a different syntax.

                                The domain language in the example is essentially XML in shorthand - with the full closing tags replaced with single closing brackets, attribute names replaced with a more positional-based syntax, etc. The complexity of definitions written in the domain language is in the same order of magnitude as that of in XML.
                                Yes.. but it a hell of a lot easier on the eyes.

                                I can see in a single blink what is going on.. I need more blinks to see what is going on in the xml based version.... just because there is more (verbose) text to read.. not because the semantics are simpeler. Does this have to be so difficult to understand? I`m not a computer.. I can only process a few words a second.

                                Comment

                                Working...
                                X