- Posted by: Olexiy Prokhorenko
- Posted on: December 29 2004 13:46 EST
I am interested in building flexible, scalable and extensible architecture of my Web project. It will be a multifunctional project. The problem is that from the very beginning we will have only _simple_ specification, with list of only _basic_ functionality and screens. When this kind of project will be ready, we will be working directly with end-users, and project will be growing.
As you can see, project requirements could be changed and new constructive features could be added at any step of projects "life". I need to build proper architecture, which we will be able to easily expand when needed.
How to do that correctly?!
I don't want to end-up with this project, wchich will consists of multiple "hacks" and "workarounds", with terrible trash in the code, and mixture of crazy database tables. Of course this "thing" will work, but I do not want such a headache.
Guys, I am asking for your help. Help me with choosing the right way with architecting such project. I've read few books on Agile Modeling, but there are a lot of books explaining Agile _project management_, but not _architecting_. I am stuck on this.
I am open for any help!!!
- Build flexible architecture... How? by damian frach on December 30 2004 03:14 EST
- Build flexible architecture... How? by Jose Ramon Huerga Ayuso on January 03 2005 15:25 EST
- Build flexible architecture... How? by Jacob Hookom on January 03 2005 23:14 EST
read this book about 4 times !!! :)
You may start with a very simple architecture:
. Struts with JSP to generate the user interface
. Regular classes to handle the business logic
. Entity beans (CMP) to access the database
As long as the requirements of the project start to be defined, you can extend this architecture in order to add more features as you need then. Please, avoid handling by hand the data access logic using JDBC: using entity beans with Container Managed Persistence (CMP) saves a lot of work, and the performance is more than decent.
Hope this helps,
Jose Ramon Huerga
Please, avoid handling by hand the data access logic using JDBC: using entity beans with Container Managed Persistence (CMP) saves a lot of work, and the performance is more than decent.
IMO the OR mapping (e.g. entity beans) should be used only for a DB caching purpose. You should avoid to create beans for big data sets.
So I believe that you should combine OR mapping (e.g. entity beans) with JDBC and sometimes even with stored procedures. If you use the DAO your business logic will not see any difference.
IMO using of the OR mapping for all data access was a major reason, why lot of EJB projects failed because of the performance.
Also IMO you should be careful with the rich OO domain model. I still believe that good ERD is good ERD ...
You should avoid to create beans for big data sets.So I believe that you should combine OR mapping (e.g. entity beans) with JDBC and sometimes even with stored procedures.
Yeah, this is true. In order to correct my previous statement, I must add that:
1) The search queries tipically used in paginated screens, should be written directly with JDBC.
2) The massive updates or deletes, should be done also in JDBC or with stored procedures.
3) The classical transactional operations (read a customer from database, create an order, assing the order to the customer, etc.) should be done with entity beans. This entity beans should be CMP, and never BMP unless you don't have any other alternative (for example, if the database runs in a mainframe: IMS, ADABAS, etc.).
Jose Ramon Huerga
I blog quite a bit on architecture and different ideas,