I'm a college student working on some mobile applications this summer and I've been using servlets /w apache tomcat on Amazon EC2 instances for my backend. Before a few weeks ago, I never had never touched servlets or even heard of object persistence or EJB's. Anyways, there's obviously a lot to know and more than 1 way to skin a cat... I'm wondering based on other peoples experiences what is the best way to get into the brunt of J2EE development to ensure that whatever I am making is scalable.
Don't optimize prematurely. (Do you really anticipate scalability issues? Most people don't have them in any meaningful way.) Don't over-complicate things: pick the lightest-weight solution that works.
It's impossible to help beyond that at this point--we know nothing about what you're doing, how you're doing it, etc. There's certainly no reason to be talking about EJBs at this point, even the easier/lighter version available EJB 3+.
Persistence is a valid question--there are a number of ways to approach it, including an ORM (Hibernate, pure JPA, iBatis, etc.), an OODB (db4o, Gemstone, etc.), or something simple-but-sometimes-makes-busy-work-but-it-depends (Spring JDBC, etc.).
Focus on making things clean and testable first.
Rahul Nair
Ranch Hand
Joined: Dec 01, 2007
Posts: 136
posted
0
Hi David,
Very Good suggestion for anyone who is new to J2EE. I still sometimes confused about when to use Abstract Classes and When to use Interfaces during application design. We know Interface is a contract which we have to complete by implementing the methods in an Interface also it is more practical thing than Abstract Classes, etc. But apart from the theoretical differences between them,
How can we decide where to use Interfaces and Abstract Classes for Design ?
Can you please explain us by giving us some real time example for this ?
If you have a method(s) that will be common to all the subclasses, using abstract class makes more sense rather than defining interface and forcing all the implementing classes to implement them.
0
