EL vs Dependency Injection

Discussions

News: EL vs Dependency Injection

  1. EL vs Dependency Injection (17 messages)

    In my blog entitled "EL vs Dependency Injection" I present an alternative solution which goes back to the traditional reference-by-name paradigm we all used with JNDI, except by replacing JNDI with EL. Using EL from Java allows you not only to 'inject' EntityManagers, but also any configuration variable or bean which can be accessed from the ELContext. When coupled with the pluggable EL resolver, its actually hard to thing of use cases where I couldn't use EL. Here is some sample code to resolve an EntityManager: public List getObjects() { EntityManager em = eval("${em}", EntityManager.class); return em.createQuery("SELECT e FROM Entity e").getResultList(); } In my code, I'm simply using a RequestFilter to insert the ${em} into the request scope, although you could equally use a custom ELResolver to resolve this variable. The eval() method is a static import which provides a shorthand for FacesContext.getApplication().evaluateExpressionGet(). There are also fewer limitations on where EL can be used compared to dependency injection. It can be used whenever an ELContext is available, and in a JSF application that is practically anywhere. I use EL for configuring beans which avoids the use of static variables that can break an application when a shared classloader is being used. /** remove the file from the filesystem when deleting */ @PreRemove public void deleteFile() { String dir = eval("${config['uploadsDir']}", String.class); File file = new File(dir, id.toString()); file.delete(); } There doesn't seem to be much opinion out on using EL from within Java. I've found it a really great way to make my code more readable and patterns more repeatable. Personally, I'd love to see it become a part of the language! What do you think? I've given some of the advantages of EL, how about some disadvantages? Performance anybody? Type safety? Tell me why I shouldn't keep using this pattern.

    Threaded Messages (17)

  2. DI in JEE?[ Go to top ]

    I'm I missing something? I thought DI was invented way before it was incorporated in JEE and was available in non J2EE from the start... PICO?, Spring?
  3. Re: DI in JEE?[ Go to top ]

    Years ago there was an interesting debate about the two options of using Dependency Injection (inversion of control) or resorting to Service Locators, or better JNDI or JNDI-based Service Locators. Here you are basically suggesting to replace JNDI with EL. I cannot see any real advantage in it, except tying your business layer to a technology/language that was intentionally developed for web pages.
  4. Re: EL vs Dependency Injection[ Go to top ]

    This article does not actually discuss any of the benefits of using this lookup pattern vs. dependency injection, unlike the title suggests. But, as that debate has been already beaten to death, it's not a big loss for the human race. What comes to the actual implementation of looking up things with EL my experiences have been negative. It does not offer code completion, type safety or support for refactoring, but still couples the parts relatively tightly. Kind of worst of both worlds, imho. /Henri Karapuu
  5. Re: EL vs Dependency Injection[ Go to top ]

    +1 for Henri
  6. Re: EL vs Dependency Injection[ Go to top ]

    Hi Henry,

    What comes to the actual implementation of looking up things with EL my experiences have been negative. It does not offer code completion, type safety or support for refactoring, but still couples the parts relatively tightly. Kind of worst of both worlds, imho.
    I had the same concerns, which is really why I wrote the article. Noticing that all my view (facelets) templates used plenty of EL which doesn't offer code completion, type safety, loose coupling or refactoring support, I began to think "Is that so bad? Why shouldn't I do this in Java?" Is there a double standard, where something that is okay in xhtml is not okay in Java? WRT coupling, well EL can be pretty flexible in this respect. Facelets has a handy method to create EL aliases () that I often use bridge independent application modules. It would be interesting to see how this idea could be applied to the Java case. Peter: This is a reference to IoC containers in the actual article, it just wasn't cut and paste here. Thanks for your comments.
  7. Re: EL vs Dependency Injection[ Go to top ]

    s/Peter/Patrick (sorry)
  8. Re: EL vs Dependency Injection[ Go to top ]

    Noticing that all my view (facelets) templates used plenty of EL which doesn't offer code completion, type safety, loose coupling or refactoring support, I began to think "Is that so bad? Why shouldn't I do this in Java?"
    1. Yes, it is so bad :) 2. And, you don't have to live with it. There are plenty of tools that give you autocompletion and refactoring support for EL expressions in templates. 3. Moreover, the soon-to-be-released next EAP version of IntelliJ IDEA supports direct EL completion and refactoring of Spring beans. So: - You can skip using managed-beans entirely, and use Spring beans instead. - You can access the Spring beans with EL directly from templates without any boilerplate and have autocompletion, refactoring etc. working! - In the Java side you can use proper dependency injection, and in the cases where lookup is better than DI, Spring also offers first class support for that, either in form of generated lookup-methods inside the calling class, or programmatic bean instantiation. /Henri Karapuu
  9. Re: EL vs Dependency Injection[ Go to top ]

    You can skip using managed-beans entirely, and use Spring beans instead.
    Why are Spring-managed beans better than (JSF, presumably) managed beans? Both are beans configured $SOMEWHERE using XML or annotations and given a name/id. Why should I prefer Spring over JSF managed beans? If all I needs is IoC, I see no reason to add Spring into the mix.
  10. Both are beans configured $SOMEWHERE using XML or annotations and given a name/id. Why should I prefer Spring over JSF managed beans? Spring container is way more convenient than JSF container. Its not only "xml" somewhere. You can easily add AOP functionalities on Spring managed bean: AOP/JMX, Logging, generic Error&Exception Handling (I like this one), but also postProcessor, a better scope management, and bean inheritances, to name few. JSF IoC is very light, its a mini IoC. I would hardly make an jee application without a Spring (or other good IoC) toolbox. And if you use Spring 2.0, i see no need (no pro) to keep JSF Managed Bean. Isn't it? Etienne
  11. Spring container is way more convenient than JSF container. Its not only "xml" somewhere. You can easily add AOP functionalities on Spring managed bean: AOP/JMX, Logging, generic Error&Exception Handling (I like this one), but also postProcessor, a better scope management, and bean inheritances, to name few. JSF IoC is very light, its a mini IoC.

    I would hardly make an jee application without a Spring (or other good IoC) toolbox.

    And if you use Spring 2.0, i see no need (no pro) to keep JSF Managed Bean. Isn't it?

    Etienne
    Right, but if all you need is a simple IoC, why Spring? I'm not anti-Spring by any means, but I've built several apps using just JSF (and EE5) IoC and they worked really well. We didn't need AOP, (and I'm not sure I see how Spring scope management is better), etc. Sure there are advantages to using something like Spring, but if You Ain't Gonna Need It, I'm not sure I see the reason for rah rah for Spring in the original post.
  12. Re: EL vs Dependency Injection[ Go to top ]

    Spring container is way more convenient than JSF container. Its not only "xml" somewhere. You can easily add AOP functionalities on Spring managed bean: AOP/JMX, Logging, generic Error&Exception Handling (I like this one), but also postProcessor, a better scope management, and bean inheritances, to name few. JSF IoC is very light, its a mini IoC.

    I would hardly make an jee application without a Spring (or other good IoC) toolbox.

    And if you use Spring 2.0, i see no need (no pro) to keep JSF Managed Bean. Isn't it?

    Etienne

    Right, but if all you need is a simple IoC, why Spring? I'm not anti-Spring by any means, but I've built several apps using just JSF (and EE5) IoC and they worked really well. We didn't need AOP, (and I'm not sure I see how Spring scope management is better), etc. Sure there are advantages to using something like Spring, but if You Ain't Gonna Need It, I'm not sure I see the reason for rah rah for Spring in the original post.

    If you aint gonna need it then dont use it, just to some it up, for many cases what JSF provides is adequate, there are no real issues with JSFs IoC except that it is just IoC nothing more nothing fancy, nothing else. Suitable for many cases, I agree ;-)
  13. I absolute agree with comment asking why Spring beans are better than JSF beans.
    Spring container is way more convenient than JSF container. Its not only "xml" somewhere. You can easily add AOP functionalities on Spring managed bean: AOP/JMX, Logging, generic Error&Exception Handling (I like this one), but also postProcessor, a better scope management, and bean inheritances, to name few. JSF IoC is very light, its a mini IoC.I would hardly make an jee application without a Spring (or other good IoC) toolbox. And if you use Spring 2.0, i see no need (no pro) to keep JSF Managed Bean. Isn't it?
    I have no issues with Spring but these types of statements continue to flow out of the Spring camp, and are bunk, and I often wonder of those making them understand JSF at all. While it is true that Spring IoC is slightly more capable than JSF IoC it does not mean that JSF IoC is not adequate to get most jobs done. Frankly I have yet to have any issues with JSF IoC and have had no pressing need to use Spring IoC to replace it. BTW, is a spring application really a jee application, and what does IoC (Spring) have to do with making a jee application. Its all of the other stuff in spring wrappers beyond the core that makes the "jee" application. And who says I need spring to make a good JSF application? I've done quite well thank-you. People who are using Spring are doing so because they are eliminating EJB's and the heavier aspects of JEE in favor of a lighter implementation. In these cases the discussion of Spring is warranted. However, in a discussion about DI I don't think Spring lends much to the conversation. If you are using Spring for your business layer then using Spring as your IoC mechanism in JSF can make sense and is easily done.
  14. Steven, Jason: It's usually not at all bad idea to go with the simplest solution that works for you. My main point was not Spring, i was just excited about this new IntelliJ IDEA feature that lets you autocomplete, navigate and refactor Spring beans from facelets EL expressions and i shared my excitement, which was probably uncalled for, sorry. However, there are also some points in Steven's posts that needs correcting:
    People who are using Spring are doing so because they are eliminating EJB's and the heavier aspects of JEE in favor of a lighter implementation.
    No, they are not. I for one am using only DI in Spring, and i do it because it's far superior to JSF DI, and yes i do know JSF very well. I would appreciate if you would not make statements why i or the Java community at large use something.
    EL in my mind is an extension to DI concept
    No, it is not. They both achieve the goal of getting a reference to an object, but do it in fundamandaly different ways.
    However, in a discussion about DI I don't think Spring lends much to the conversation.
    While you express this as only personal opinion, it is one of the most strange personal opinions i'v heard. Spring is the one that popularized the entire concept of DI, it is the benchmark of DI, and still to date the most full featured implementation of DI. It lends awfully lot to most any conversation about DI, and if you feel that JSF DI and Spring DI are equal, i can only conclude that you are not familiar with Spring DI. But still, there is nothing wrong with using only JSF DI, it's perfectly adequate for many needs. Just don't spread FUD against those who need more. /Henri Karapuu
  15. While you express this as only personal opinion, it is one of the most strange personal opinions i'v heard. Spring is the one that popularized the entire concept of DI, it is the benchmark of DI, and still to date the most full featured implementation of DI. It lends awfully lot to most any conversation about DI, and if you feel that JSF DI and Spring DI are equal, i can only conclude that you are not familiar with Spring DI.
    So now that we have both neutralized our comments maybe the discussion can get to the matter of EL vs DI and what is the difference and what role, if any, does EL have in programming. BTW. I did acknowledged Spring DI > JSF DI and yes it is the grandfather. I suspect others may now tire of this thead as well.
    EL in my mind is an extension to DI concept No, it is not. They both achieve the goal of getting a reference to an object, but do it in fundamandaly different ways.
    Let me rephrase this in terms of Spring and JSF. If you use Spring DI in JSF then you still use EL. So my point here is that EL is complimentary to DI. One might say that Spring DI becomes the EL VariableMapper thats all. So they are thus in perfect harmony. Back to the original question however, unless you are just out to write your own variable mapper for very specific implementation why would you do so given Spring and other solutions. Thus EL was designed and should be used in narrow manner. With reference to Facelets, if there is now an editor that will write all the glue code for you then I suppose in that scenario there is no need for EL. But that was not the original question.
  16. Let me rephrase this in terms of Spring and JSF. If you use Spring DI in JSF then you still use EL. So my point here is that EL is complimentary to DI.
    Eh.. I think you have some confusion about the meaning of dependency injection. At their core both the JSF managed bean facility and Spring application context are factories for creating new objects. Both the JSF and Spring facilities can be used in two ways: you can lookup the objects, or they can inject the objects to your beans (usually using setters). When you use EL, you are doing a 'lookup'. That is NOT dependency injection.
    One might say that Spring DI becomes the EL VariableMapper thats all.
    No, one may not :) Saying that makes absolutely no sense.
    maybe the discussion can get to the matter of EL vs DI and what is the difference and what role, if any, does EL have in programming.
    I think i pass this one :) It's friday and i want beer. Peace :) /Henri Karapuu
  17. Re: EL vs Dependency Injection[ Go to top ]

    You can skip using managed-beans entirely, and use Spring beans instead.

    Why are Spring-managed beans better than (JSF, presumably) managed beans? Both are beans configured $SOMEWHERE using XML or annotations and given a name/id. Why should I prefer Spring over JSF managed beans? If all I needs is IoC, I see no reason to add Spring into the mix.
    Easy to say, the JSF managed bean facilities are very basic, if you use EJB3 or Spring instead of JSF you will gain a lot of added functionality. The JSF designers were aware of this and basically made a general hook point via the variable resolvers, because they knew, JSF needed something like this but in the long run other containers/frameworks simply will and can provide more than what pure JSF does. If you can live with what JSF provides then sure there is no reason to add spring to the mix, but many people simply need more.
  18. Re: EL vs Dependency Injection[ Go to top ]

    I honestly think everyone here is missing the point in both the original post and follow on comments. In my mind EL and DI are complementary. I will state before I go on that I have a JSF bias but here is my take. EL for me breaks down into two distinct parts. First there is the Variable Resolver. The variable resolver can be thought of as the DI piece in which you are going to map a variable name to an object instance. It is up to your managed bean facility (now called ELContext) to figure that out. It can be Spring or any other type of facility. Once you have the bean injected the next part is the property/method resolvers. The property resolver allows you to access bean properties (setter/getters). The method resolver allows you to access bean methods. Together they give you a mechanism to walk object graphs. Finally the expression language gives you an expression evaluator that provides simple langauge syntax and semantics. These include Arithematic, Logical, Relational operators, type conversion, collection (Arrays, Maps) constructs. While you might use it in pure java not sure why you would want to do it. It solves a problem mainly encountered in XML based tag systems where things like attributes have values that need to be expressed and parsed in real time. In JSP/JSF the EL can be evaluated either at compile time (traditional JSP mechansim) or at run time (JSF mechanism). The new EL 2.0 was designed to support either in JSP and unify the language. So it is not EL vs Dependency Inject it is EL and how it can be used with DI. EL in my mind is an extension to DI concept and even with Spring the two can be complementary.