Java EE Patterns Book On Kindle--Don't Buy It Lend It (For Free)
Real World Java EE Patterns--Rethinking Best Practices [Kindle Edition] book is available worldwide (also Japan and India) on Kindle:
However, "Real World Java EE Patterns" is also available for free lending without any due dates. See how it works.
Because of free lending, the digital edition of this book is only going to be available on Kindle.
I'm curious, whether you like it. Feedback is highly appreciated!
Hello, Mr. Bien.
I've purchase and am reading your new edition of Java EE Patterns and greatly appreciate your various blog entries as well as the formal book.
I'm creating a project consisting of the Entity-Control-Boundary (ECB) Patterns as described in the book. I am taking into account your recommendations in the Conventions sections as well as the conditions in the Anti-Patterns sections.
I am also creating a client project that includes simple concrete classes (Transfer Objects), which the entities extend, as well as the service interface. This is basically an SPI except I'm using concrete classes instead of abstract classes.
I have an appreciation for package structure and naming conventions; I appreciate your condition that boundaries shouldn't having a "meaningless ending".
When applying your recommendations I have found that I'll have three classes with the same name: the transfer object, the entity and the service or gateway. Have you assembled a 'best practices' document in package structure and naming convention. Or, are you planning to provide a sample project having some complexity that would illustrate the organization of objects? If not, can you provide some commentary on this?
I suppose I could simply append the pattern classifier on the class names. For instance, -TO, -Entity, -Bean. But, I wanted to get your thoughts as you seem to apply some rigour to your naming/packaging decisions.
Posted by Mark on November 16, 2012 at 10:52 PM CET #
Hello again, Mr. Bien.
I believe I've resolved my confusion around naming. I looked at your Java EE 6: Simplicity by Design article (http://www.oracle.com/technetwork/issue-archive/2011/11-jan/o11java-195110.html) as well as the lightfish source code from github and found both illuminating. You have the obvious entity names, then there are the 'Provider' / 'Store' within control and finally the exposing service having a 'verb' name in boundary (or -Broker, Controller). I believe there still might be a benefit to providing a collection of ECB solutions and the naming used on the objects. But, for now I'm feeling more comfortable having used lightfish as an implementation example.
Posted by Mark on November 19, 2012 at 08:22 PM CET #