Esta página muestra, con el propio ejemplo de Persona que ya se usa en el curso (persona-form.jsp, PersonaControladorServlet, PersonaDAO), qué cambia entre resolver el alta de una persona solo con JSP (sin ningún Servlet de por medio) y resolverla con la arquitectura MVC que ya está documentada en Controlador-PersonaControladorServlet y Validación-de-unicidad-de-código.

La idea es usarla como puente: antes de llegar a MVC, se puede mostrar la versión "ingenua" (JSP puro) de este mismo formulario, y después, al llegar a la unidad de MVC, contrastarla con la versión real que ya tienen en el repo.

Esta tabla es la clave de por qué Persona sí necesita Servlet y Área del triángulo o Promedio de notas no: acá hay algo que debe persistir entre un pedido y el siguiente (la lista de personas ya cargadas), y esa persistencia solo puede vivir en un objeto del lado del servidor (el DAO) — no en el request de una sola pasada que usa JSP puro.

Esta sería la versión "ingenua" — sirve para mostrar el límite de lo que se puede hacer solo con JSP, antes de introducir MVC.

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib prefix="c" uri="jakarta.tags.core" %>
<form action="resultado.jsp" method="post">
    <label>Código: <input type="number" name="codigo" required /></label>
    <label>Nombre: <input type="text" name="nombre" required /></label>
    <button type="submit">Guardar</button>
</form>

<c:if test="${not empty param.codigo}">
    <p>Persona registrada:</p>
    <p>Código: ${param.codigo}</p>
    <p>Nombre: ${param.nombre}</p>
</c:if>

Con esto se puede mostrar que el formulario "funciona" — pero cada envío es una isla. Si dos estudiantes cargan el código 5 dos veces seguidas, no hay forma de que la página se dé cuenta ni de avisar. Ese es exactamente el problema que dispara la necesidad de un Modelo (DAO) y, con él, un Controlador (Servlet) que lo consulte.

Este código no es un ejemplo nuevo — es literalmente el que ya está en proyectos-teoricos/mini-crud2/src/main/java/controlador/PersonaControladorServlet.java, documentado en la página Validación-de-unicidad-de-código:

private void agregar(HttpServletRequest request, HttpServletResponse response)
        throws IOException, ServletException {
 
    PersonaVO personaParaFormulario = null;
    int codigo = 0;
    String nombre = request.getParameter("nombre");
 
    // 1. Obtener y validar el código
    codigo = Integer.parseInt(request.getParameter("codigo"));
    personaParaFormulario = new PersonaVO(codigo, nombre.trim());
 
    // 2. 🛑 VERIFICACIÓN DE UNICIDAD USANDO EL DAO 🛑
    PersonaVO personaExistente = dao.obtenerXCodigo(codigo);
 
    if (personaExistente != null) {
        // Error: Código duplicado
        request.setAttribute("error",
                "Error: El código " + codigo + " ya está registrado. Ingrese uno diferente.");
        request.setAttribute("persona", personaParaFormulario); // Mantener datos
 
        // Usar FORWARD para volver al formulario y mostrar el error/datos
        request.getRequestDispatcher("/WEB-INF/vista/persona-form.jsp").forward(request, response);
        return; // Detener la ejecución
    }
 
    // 3. Si es único (personaExistente == null), agregar
    dao.agregar(personaParaFormulario);
 
    // 4. PRG (Redirección al listado)
    response.sendRedirect(request.getContextPath() + "/persona");
}

La vista correspondiente (persona-form.jsp) ya está documentada tal cual en Uso-de-JSTL / Validación-de-unicidad-de-código, usando ${requestScope.error} y ${requestScope.persona.codigo} en vez de ${param.codigo} — porque ahora el dato no viene directo del formulario, sino de lo que el Servlet decidió guardar en el request después de consultar al DAO.

Con Área del triángulo o Promedio de notas, cada cálculo depende únicamente de lo que llegó en ese mismo formulario — no hace falta recordar nada de pedidos anteriores. Con Persona, en cambio, la pregunta "¿este código ya existe?" no se puede responder sin memoria entre pedidos. Ahí es donde JSP puro se queda corto y aparece la necesidad real de MVC: un Modelo que persista datos, y un Controlador que lo consulte antes de decidir qué mostrar.

MVC · Servlet · Controlador · PersonaDAO · PersonaVO · doPost · forward · PRG · requestScope · param · unicidad de código · persistencia en memoria

Ver también: Uso-de-JSTL, Validación-de-unicidad-de-código, Comparativa-persona-form (esa página compara scriptlets vs EL/JSTL dentro de la vista; esta página compara con/sin Servlet en la arquitectura completa — son ejes distintos).

← Comparativa persona-form.jsp · 🏠 Inicio · Introducción: BD + Web →