01 December 2004
I just finished reading through Ted Neward’s Effective Enterprise Java book (ISBN 780321130006) and it is a must read for any enterprise .NET developer.
<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />
I hear it now. “What?! A Java book for .NET developers? Rocky, you’ve gone over the edge!”
No, I haven’t gone over the edge, and YES, absolutely a Java book for .NET developers.
It would be extremely foolish for any enterprise developer to read only .NET or Java information. It isn’t like either technology as a monopoly on smart, eloquent technical experts. On top of that, the two platforms are so similar at an architecture and software design level that the same guidelines and best practices apply equally to both.
So yes, go out and read Ted’s book. Every single item in the book has direct applicability to .NET. Sure you’ll need to translate some terminology to the .NET world, but that’s a minor thing. The important thing is that you’ll learn a whole lot about the good, the bad and the ugly when it comes to creating enterprise applications.
The truisms for minimizing network costs (latency, bandwidth, etc.) are universal. The tradeoffs when dealing with shared state and mapping state between objects, databases and XML are universal. The need to reduce locking and blocking are universal. The OO design patterns that address these issues in Java are exactly the patterns that apply in the .NET space as well.
And since this is a book about enterprise issues, there’s relatively little code and you can safely ignore virtually all of it. No offense to Ted, but this book doesn’t need any of the Java code. I’m sure he put it in there to make it actually feel like a Java book. No, the value is in the sometimes irreverent yet thorough discussion of the issues and the tradeoffs involved in addressing those issues.
Honestly, if this book used more universal terminology and skipped the few code examples it has, it would be a universal must-have resource for any modern enterprise platform – Java, .NET or whatever. I contend that it still fills this role, albeit with the need for .NET readers to mentally translate some terminology into our world. And that’s a small price to pay.