Understanding Programs, JavaEE MVC, and Why Maps Can Replace JavaBeans

1. My Understanding of Programs

As a programmer, I view a program as the combination of code and data; writing a program is akin to cooking where data are the ingredients, code is the culinary skill, and the resulting software is the dish. Both good ingredients and good technique are essential.

I categorize data into two types:

Landing data are persisted on storage devices such as disks, databases, images, logs, or any data that has a fixed carrier and does not disappear instantly.

Non‑landing data exist only in memory or during network transmission, disappearing after use—for example, HTTP requests from a browser or data held temporarily before rendering on a page.

2. JavaEE MVC Design Pattern

Java popularized the MVC (Model‑View‑Controller) pattern, which I prefer to read as VCM: View (frontend pages), Controller (receives page data and invokes backend business models), and Model (handles business logic). The classic three‑tier MVC evolves into a multi‑layer architecture: View + Controller + Service + DAO + Database, as illustrated in the following diagrams.

The red lines represent user requests, the blue lines represent server responses; all data transferred between layers are non‑landing data.

In Java projects, these transfers are usually done with JavaBeans. A typical JavaBean looks like the image below.

3. NoJavaBean

Although JavaBeans are deeply ingrained in many Java developers' habits, they have several drawbacks:

Too many Bean classes: a large enterprise project may generate a Bean for each database table, leading to thousands of trivial classes.

Increased coupling between layers: each layer passes business data wrapped in Beans, making changes in one layer ripple through others.

Duplicate data dictionaries: field names are transformed (e.g., USER_NAME → userName), obscuring the original database semantics.

Complex permission‑related refactoring: in one project, using Beans for data transport caused a painful redesign when handling fine‑grained data permissions.

Layer‑specific responsibilities are blurred because the same Bean travels across View, Controller, Service, and DAO.

Given these issues, I propose abandoning JavaBeans in favor of a more flexible structure.

4. The Universal Map (Key‑Value Pair)

Key‑Value (KV) structures are supported by virtually every language and underpin many modern technologies such as MapReduce, iBATIS, and JSON. In my projects, replacing JavaBeans with Map objects (or List<Map> for collections) streamlined data handling, reduced boilerplate, and improved cross‑layer compatibility.

Advantages of using Map :

Uniform access syntax: in JavaScript you use obj.xxx or obj[xxx] ; in Java you use map.get(xxx) or map.put(xxx, value) . Keys are simple strings that can be defined on the fly.

Cross‑platform: KV structures exist in almost all mainstream technologies, making data transfer portable.

Mature algorithms: the Map data structure is well‑optimized for complex calculations.

Thus, a Map can serve as a lightweight, adaptable alternative to JavaBeans for data transmission across application layers.

Source: http://www.cnblogs.com/sharpxiajun/archive/2011/09/28/2193620.html