Lecture 15: JavaBeans and MVC

Outcomes and readiness

You can recognize a classic JavaBean, divide responsibilities among Model-View-Controller, and trace a request without placing SQL or business rules in the view. Readiness: classes, servlets, JDBC repository, and HTML output.

Terminology first

In this outline, JavaBeans is taught as the classic component/property convention: a public class, commonly a public no-argument constructor, private properties exposed by naming-convention getters/setters, and optional serializability/events. This is not automatically the same as a Jakarta CDI managed bean, Enterprise JavaBean, or a plain domain object.

public class CourseBean implements java.io.Serializable {
    private String code;
    private String title;

    public CourseBean() {}
    public String getCode() { return code; }
    public void setCode(String code) { this.code = code; }
    public String getTitle() { return title; }
    public void setTitle(String title) { this.title = title; }
}

MVC responsibilities

• Model: domain data/rules and application services; persistence behind a repository.
• View: presents a prepared view model and escapes output for its context.
• Controller: accepts request input, invokes a use case, selects status and view/representation.

flowchart LR
  R[HTTP request] --> C[Controller servlet]
  C --> M[Application/domain model]
  M --> P[Repository]
  C --> V[View or JSON serializer]
  V --> S[HTTP response]

Worked request

Controller reads code, validates shape, calls FindCourse, and receives found/not-found/failure. It creates a small view model and forwards to a template or serializes JSON. The view displays; it does not open a database connection. The repository queries; it does not choose an HTTP status.

Faded example

A JSP-like view calls JDBC and decides whether a user may edit. Hint: which rules are presentation? Solution: move authorization/use case to controller/application service and persistence to repository; pass only the prepared result to the view.

Common mistakes

• MVC does not mean every class name must end in Model/View/Controller.
• A mutable bean with unrestricted setters may violate domain invariants; use it as a transfer/view object when appropriate, not automatically as the domain model.
• Controller code can still become too large; application services hold reusable use cases.

Practical – DI322-LAB15

Refactor a single servlet containing validation, SQL, HTML strings, and authorization into controller, use-case service, repository, and view/serializer. Create a CourseBean or view model only where property conventions help. Unit-test the use case without a servlet container and integration-test controller mapping.

Independent check

Q1 Classic bean property for getTitle/setTitle? title. Q2 Which MVC part chooses HTTP/view flow? Controller; business result comes from model/service.

Homework – DI322-A15-H1

Draw and explain MVC for “submit assignment.” Include validation, authorization, transaction, upload storage, view model, and five failure paths. Rubric: boundaries 4, flow 2, failures 2, security 1, clarity 1.

Revision

MVC separates reasons to change. A bean convention helps tools discover properties, but it does not replace domain design.