Question

The project which I am going to start is my first project and it is very big. Though it’s a great opportunity for me, I don’t want me to trapped myself in a messed-code in the end so I have made a whole design of the software (software architecture) divided it into three tiers:

1. Presentation Tier —- (will be implemented through Java Swing)
2. BusinessLogic Tier — (will be implemented through EJB technology)
3. DatabaseLayer ——- (will be implemented with the help of Hibernate)

Q1. Which Tier should I select to start with?

I don’t have any experience of Standard Product Development environment but I am sure that there is some specific order which is better than other.

Q2. I think that these things come under Good Design Principles and Best Practices. I have searched the internet for these kinds of resources and have found some good resources too but I would be grateful if you recommend me some resources that you know have short, to-the-point and quality content?

Answer 1

“my first project and it is very big”

Please don’t do that.

Please do a small project first.

1. Write the “model” (business logic) first. This will be very difficult, since it’s your first project. Keep it small and focused on just business logic that you can test and prove that it works.

2. Throw that away.

Now do another project.

1. Write the “model” (business logic) first. Based on lessons learned during the first project this will be much better. This will be hard, since it’s your second project. Keep it small and focused on just business logic that you can test and prove that it works.

2. Write the persistence and the object-relational mapping second. Adding database persistence will be very hard, since it’s only your first database project, and only your second project.

3. Throw that away.

Now, you have some idea what you’re doing. Start a third project.

1. Write the “model” (business logic) first. Based on lessons learned during the first two projects this will be much better. By now, this will still be a lot of work because you finally understand what you’re doing. The work, however, will no longer involve technical issues, it will now involve real issues around use cases and what the application actually does.

2. Write the persistence and the object-relational mapping second. Based on lessons learned during the first projects this will be much better. This will still be hard. Nothing makes this easy. It’s only your second time, so you’ll still make mistakes; there will be fewer mistakes.

3. Write the presentation last. Always.

This is actually the fastest way to do a large project when you don’t already know the technology.