Skip to main content

Home/ SoftwareEngineering/ Group items matching "DI" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Implementing the Builder Pattern using the Bean Validation API - Musings of a Programming Addict - 0 views

  • invariants
  • customer's last name must not be null
  • must be between 3 and 80 characters long
  • ...23 more annotations...
  • @Size(min = 3, max = 80)
  • @NotNull
  • LastName
  • inner class Builder is in charge of creating Customer instances
  • mandatory fields – either primitive (e.g. id) or annotated with @NotNull (e.g. lastName) – are part of the builder's constructor
  • all optional fields setter methods on the builder are provided
  • newly created Customer instance is validated using the Validator#validate() method
  • impossible to retrieve an invalid Customer instance
  • extract the validation routine into a base class:
  • abstract class AbstractBuilder<T>
  • T build() throws ConstraintViolationException
  • protected abstract T buildInternal();
  • private static Validator validator
  • Concrete builder classes have to
  • extend AbstractBuilder
  • must implement the buildInternal() method:
  • Builder extends AbstractBuilder<Customer>
  • @Override protected Customer buildInternal()
  • Implementing the Builder Pattern using the Bean Validation API
  • variation of the Builder design pattern for instantiating objects with multiple optional attributes.
  • this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)
  • or providing setter methods for the optional attributes
  • (require objects to be mutable, can leave objects in inconsistent state)
kuni katsuya

Dependency injection discourages object-oriented programming? @ Blog of Adam Warski - 0 views

  • Dependency injection discourages object-oriented programming?
  • if you’re using DI, and you have an X entity, do you have an XService or XManager with lots of method where X is the first argument?
    • kuni katsuya
       
      evidence of the anti-pattern of procedural design in a java ee6 cdi application
  • previous way is more procedural
    • kuni katsuya
       
      ie. ProductService.ship(Product,Customer)
  • ...12 more annotations...
  • service/manager is a set of procedures you can run, where the execution takes a product and a customer as arguments
  • better
  • OO approach
  • not saying that achieving the above is not possible with a DI framework
  • only that DI
  • encourages the ProductService approach
    • kuni katsuya
       
      well, dependency injection, but moreover, the soa approach to service design tends to force otherwise intelligent software engineers into doing procedural design the services just end up being bags of method calls that implement any type of behavior, with the domain objects or entity beans being reduced to mere data structures with little responsibility or behavior beyond persistence. (which, in this anti-pattern, is typically mostly provided by the repository or dao class! ie. domain object crud)
  • it’s just easier
    • kuni katsuya
       
      ... if you just blindly follow the anti-pattern, of course  ;)
  • many benefits
    • kuni katsuya
       
      with the procedural approach, you also cannot implement polymorphic behavior, for instance
  • builder
  • fluent interface
  • it’s not for small projects
    • kuni katsuya
       
      fuckwhat? small or big matters not. if di is applied poorly, regardless of project size, it's an anti-pattern! disregard these comments!
  • problems with DI frameworks:
    • kuni katsuya
       
      not sure i agree with these points, but will refuse in a later sticky note
kuni katsuya

JPA/Hibernate Ternary Association « Fulvio Di Marco: just a personal code notepad… - 0 views

  • JPA/Hibernate Ternary Association
  •  
    "JPA/Hibernate Ternary Association"
kuni katsuya

Dependency Injection in Java EE 6 - Part 1 - 0 views

  • Dependency Injection in Java EE 6 - Part 1
  • high-level look at CDI, see how it fits with Java EE overall and DIscuss basic dependency management as well as scoping.
  • CDI is designed to solve
  • ...21 more annotations...
  • highly type-safe
  • consistent
  • portable
  • CDI enhances the Java EE programming model in two more important ways
  • allows you to use EJBs directly as JSF backing beans
  • CDI allows you to manage the scope, state, life-cycle and context for objects in a much more declarative fashion, rather than the programmatic way
  • CDI has no component model of its own
  • set of services that are consumed by Java EE components such as managed beans, Servlets and EJBs.
  • well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations.
  • Managed beans
  • @ManagedBean
  • annotation
  • CDI also integrates with JSF via EL bean name resolution
  • CDI does not DIrectly support business component services such as transactions, security, remoting, messaging
  • Dependency Injection for Java
  • JSR 330
  • JSR 330 defines a minimalistic API for dependency injection solutions and is primarily geared towards non-Java EE environments.
  • Figure 1 shows how CDI fits with the major APIs in the Java EE platform.
  • none of this uses string names that can be mistyped and all the code is in Java and so is checked at compile time
  • Qualifiers
  • are additional pieces of meta-data that narrow down a particular class when more than one candidate for injection exists
kuni katsuya

Dependency Injection in Java EE 6: Conversations (Part 4) - 0 views

kuni katsuya

Article Series: Migrating Spring Applications to Java EE 6 - Part 1 | How to JBoss - 1 views

  • In fact people still love those books without realizing that the world has changed dramatically ever since
  • The reality check here is to wonder whether the rhetorics set forth by Rod Johnson in his 2003/2004 books are still actual today
  • So if you still care about those books, the best way to show your appreciation is probably to use them as your monitor stand
  • ...21 more annotations...
  • The discussion whether or not to use Spring vs. Java EE for new enterprise Java applications is a no-brainer
  • Why migrate?
  • since then fallen a prey to the hungry minds of Venture Capitalists and finally into the hands of a virtualization company called VMware
  • While the different companies and individuals behind the Spring framework have been doing some work in the JCP their voting behavior on important JSRs is peculiar to say the least
  • outdated ORM solution like JDBC templates
  • some developers completely stopped looking at new developments in the Java EE space and might have lost track of the current state of technology
  • size of the deployment archive
  • fairly standard Java EE 6 application will take up about 100 kilobytes
  • comparable Spring application weighs in at a whopping 30 Megabytes!
  • Lightweight
  • Firing up the latest JBoss AS 7 Application Server from scratch and deploying a full blown Java EE 6 application into the server takes somewhere between two and five seconds on a standard machine. This is in the same league as a Tomcat / Spring combo
  • Dependency injection
  • Java EE 6, the Context and Dependency Injection (CDI) specification was introduced to the Java platform, which has a very powerful contextual DI model adDIng extensibility of injectable enterprise services
  • Aspect Oriented Programming
  • “AOP Light” and this is exactly what Java EE Interceptors do
  • common pitfall when taking AOP too far is that your code might end up all asymmetric and unreadable. This is due to the fact that the aspect and its implementation are not in the same place. Determining what a piece of code will do at runtime at a glance will be really hard
  • Testing
  • With Arquillian we can get rid of mocking frameworks and test Java EE components in their natural environment
  • Tooling
  • capabilities comparison matrix below to map Spring’s technology to that of Java EE
  • Capability Spring JavaEE Dependency Injection Spring Container CDI Transactions AOP / annotations EJB Web framework Spring Web MVC JSF AOP AspectJ (limited to Spring beans) Interceptors Messaging JMS JMS / CDI Data Access JDBC templates / other ORM / JPA JPA RESTful Web Services Spring Web MVC (3.0) JAX-RS Integration testing Spring Test framework Arquillian *
1 - 8 of 8
Showing 20 items per page