How To Deal With Interfaces In Java EE 6 (or no more Impl)
In Java EE 6 interfaces became absolutely optional. Neither in EJB 3.1, nor CDI / JSR-330 you need interfaces. You can inject classes directly. They will be still proxied, so all aspects like persistence, transactions, interceptors, decorators are still available. So you are no more forced to implement interfaces by the container
used for:
Strategy Pattern: there are already several implementations of an algorithm or concept
Layering: there is a clear need to hide e.g. an ugly implementation of a legacy framework
API (not very common): you have to expose a API, which gets implemented by SPI (e.g. JDBC)
If you introduce interfaces intentionally - and not as a general rule, you will considerably reduce the number of files. Your code becomes easier to understand and so maintain
Even for decoupling purposes, interfaces are no more needed
"Contract First", "Coding To Interfaces" or "Decoupling"
is not a reason to introduce an interface for everything
GDS/Tide project represents the Data Services part of GDS
comparable to LiveCycle Data Services, which is neither open source nor free, as it provides similar features such as client container of managed entities, data paging, and integration with server components, but it is based on completely different principles:
All managed entity instances are unique in a Tide context
Tide keeps the classic three layers web architecture, when LCDS removes the service layer, and is some kind of remote JPA provider for Flex applications
Tide approach is to minimize the amount of code needed to make things work between the client and the server
principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring, EJB 3 and CDI are also available
need to compile your MXML/AS sources with the granite-essentials.swc and granite.swc libraries
Java Persistence API (JPA)
Java Contexts and Dependency Injection (CDI)
Java Authentication and Authorization Service (JAAS)
Java Authorization Contract for Containers (JACC)
JavaMail API
Bean Validation
Enterprise JavaBeans
stop asking themselves how this solution could be improved upon
It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.
but that might be too high-level for your taste. Their are other, less-abstract options.
exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."
Utter nonsense and dishonest false advertising
Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.
Pffffff. It's a trivial requirement which I can solve in my framework with two lines of code in a @Disposes method. Did you see any connection handling in the code above?
I mean, seriously guys. The Spring stuff is trivial and not even very elegant. I guess it's easier for me to see that, since I spent half my career thinking about data access and designing data access APIs. But even so...
I don't understand. You hate the ability to write typesafw SQL that much?
Gavin King
Methods with long argument lists are a code smell.
It's something Spring copied from Hibernate 1.x, back in the days before varargs
It's something we removed in Hibernate2 and JPA.
there are a bunch of people
who don't want to use JPA.
They don't understand, or see the value of, using managed objects to represent their persistent data.
Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?
Are you working from some totally bizarre metric where you measure code quality by number of classes?