It's astonishing how obvious and much simpler concepts become when you keep asking those basic questions. We have faced many projects where fundamental design decisions were based on various reasons but not on those basic ones. Many systems provide a steep learning-curve in the beginning of a project (the "cats and dogs" samples) but keep slowing you down in later phases when you have to "really" understand what's going on under the magic hood of a framework. In those phases ("80% done") we usually start to spend a lot of time becoming an expert and tweaking the framework: We have to understand the implicit dependencies (rendering cycles, AOP, annotations, ...), the layers, the configuration models and the flow. The consequences are slower development, less scalability, hard testing and error chasing (e.g. due to runtime errors instead of compile time ones).
So cutting it down to our basic questions: We needed something to quickly create straight forward web applications and keep them maintain- and scalable throughout their life-cycle. If we'd focus on what we really need, we could keep the concepts easier, the code base smaller and thereby make it faster to learn for colleagues.
The basic principles are simple:
- An Action processes a request, calls business logic and creates a model
- A View renders the model. Views are pure HTML pages
- The mapping between requests, actions and views is simple but extensible. No XML configuration
- Views are transformed to Java classes and compiled at runtime
- Views contain Compile-time Tags. This is a fundamental difference from typical tag-approaches and the reason why MVC can do without an expression language or reflection based code evaluations. It's all compiled and therefore faster, more maintainable and much easier to understand and debug
- VrameWork MVC supports a conversation-state for working with several browser windows without losing the state and templates for easier page creation and maintenance
- For more details, please refer to http://www.vramework.org/Eng/AboutMVC.html
The sample application (http://www.vramework.org/Eng/Downloads.html) shows those concepts and is at the same time a tutorial with a Help link on each page explaining how it works.
The sample application uses VrameWork JdbcMap as a simple row-to-object data access layer.
- The mapping information and SQL statements are defined in simple text files
- Mapping files are - if wanted - generated on the fly automatically. The generated files contain DDL and CRUD operations: Create tables and views (for class hierarchies), query, insert, update and delete objects.
- The translation process between rows and objects is compiled. This is an important advantage in case of a data driven application which has to translate billions of rows to objects. Most O/R mappers have to rely on reflection to translate rows to objects and vv. JdcbMap does not because it creates and compiles so called Row Translators at runtime
- It provides generic classes for executing the SQLs in the mapping files and resolving class hierarchies
- JdbcMap creates efficient statements (e.g. outer joins) for loading lists and referenced objects (avoiding N+1 query problem), for loading polymorphic lists and lists and relationships and for loading 1:n relationships
- More details can be found at http://www.vramework.org/Eng/AboutJdbcMap.html
So what we have is not a full blown framework covering "anything" but a simple and open concept, avoiding "implicit magic" by explicit design.