Speaker 1: Okay, let's untack this. Welcome to the deep dive. We're
Speaker 1: all about taking complex topics, cutting through the noise, and
Speaker 1: really giving you those vital insights quickly, thoroughly, and hopefully
Speaker 1: without that feeling of being overwhelmed. Exactly today we're diving
Speaker 1: deep into Java MVC one point zero. It's well, it's
Speaker 1: a pretty foundational design pattern, really critical if you're building
Speaker 1: modern web apps, cloud services, even micro services. And our
Speaker 1: guy for this is Peter Spieth's excellent book Beginning Java
Speaker 1: Mvc one point zero.
Speaker 2: Yeah, it's exciting stuff because we're not just looking at,
Speaker 2: you know, a technology, We're digging into a fundamental design pattern,
Speaker 2: one with some serious history behind it. Our goal here
Speaker 2: is to give you a clear, kind of structured understanding
Speaker 2: of Java mvc. What are the core pieces? How does
Speaker 2: it fit into the whole Java enterprise world. Yeah, and
Speaker 2: you should walk away with some practical insights, not just
Speaker 2: the what, but the why? Why does this pattern even matter?
Speaker 2: What does the lit developers actually do?
Speaker 1: Absolutely? So, let's start big picture model. You control NBC.
Speaker 1: It's not just Java, right, it's this fundamental software design pattern.
Speaker 2: Oh yeah, fundamental.
Speaker 1: It breaks down complex apps into three distinct roles, three
Speaker 1: interconnected pieces. Think of it like I don't know a
Speaker 1: well oiled machine, where each part has a specific job.
Speaker 2: A good analogy.
Speaker 1: So at the core you've got the model. This is
Speaker 1: all about the application data, specifically the data the user
Speaker 1: sees and might change. Right the state and the key
Speaker 1: thing is the model is totally ignorant. It has no
Speaker 1: idea how that data gets presented or how the application flows.
Speaker 1: It's just the data, the source of truth.
Speaker 2: Agnostic that's the word often used. It's data centric, not
Speaker 2: presentation aware.
Speaker 1: Then you have the view, Its job is purely presentation.
Speaker 1: How does the model's data look to the user? All
Speaker 1: the interactive bits, inputs, buttons, menus. That's the view.
Speaker 2: Could be a desktop gooi, a mobile app screen, or
Speaker 2: most often for us, a webpage.
Speaker 1: It's the user's window basically exactly. And finally, the controller.
Speaker 1: This is the coordinator, the brains. Maybe it handles user input,
Speaker 1: It talks to the model to get or update data,
Speaker 1: contains the application logic, calculations, data transformations, that kind of.
Speaker 2: Thing, And crucially it decides how data gets stored or retrieved,
Speaker 2: maybe from a database.
Speaker 1: Right, But it doesn't care about how the view looks.
Speaker 1: Its job is managing the flow, not painting.
Speaker 2: The picture precisely keeps things separate.
Speaker 1: Okay, to make this more concrete, let's use this book
Speaker 1: club example application from the book. We'll keep coming back
Speaker 1: to it.
Speaker 2: Good idea.
Speaker 1: So in book Club, the books themselves, their rental status,
Speaker 1: member details. All that stuff lives in the model.
Speaker 2: The core entities.
Speaker 1: The web page is showing search results, the member sign
Speaker 1: up form, the menus that's all view, the user interface,
Speaker 1: and the controller that's the logic that takes your search
Speaker 1: request or updates a book status when you rent. It
Speaker 1: fetches member info from the database and then decides which
Speaker 1: view to show next.
Speaker 2: It handles the doing part based on user actions.
Speaker 1: Exactly the logic behind it all.
Speaker 2: And if you connect this to the bigger picture, like
Speaker 2: you said, NBC isn't new. It goes way back.
Speaker 1: Yeah, you mentioned history, right back.
Speaker 2: To the nineteen seventies small talk. Originally, it didn't get
Speaker 2: the explicit MVC name until the late.
Speaker 1: Eighties wow, seventies.
Speaker 2: But it's real power. Well that became obvious in the
Speaker 2: nineties with the Internet boom. The pattern adapted surprisingly well
Speaker 2: to web applications, even though AHGTP is inherently stateless.
Speaker 1: That statelessness is always the challenge, isn't it always?
Speaker 2: And it led to specific Web NBC challenges like how
Speaker 2: do you keep track of a user across multiple requests?
Speaker 2: That's where sessions came in, usually managed by frameworks using
Speaker 2: cookies okay? Or how do you cleanly get modeled data
Speaker 2: into the view. Templating engines solve that thing things like
Speaker 2: user dot first.
Speaker 1: Name right, accessing the data easily, and.
Speaker 2: How do you update the page? We moved from reloading
Speaker 2: the entire page to partial updates using scripts like ajax,
Speaker 2: much smoother. And while other patterns like MVVM came along,
Speaker 2: often adding more automation for data binding, they still build
Speaker 2: on that core MVC idea of separating concerns.
Speaker 1: That's a great historical context. So if MVC is that old,
Speaker 1: what makes Java MVC this JSR three seventy one the
Speaker 1: modern choice for enterprise JABA.
Speaker 2: Good question. Java MVC is the dedicated standardized framework for
Speaker 2: Java EE eight and now Deakarta E eight and later.
Speaker 2: It filled the gap many developers felt.
Speaker 1: Was there a standard was needed?
Speaker 2: Kind of yeah, And it's important to remember JSR three
Speaker 2: to seventy one defines the interface. You need an implementation
Speaker 2: like eclips Crazo to actually use it.
Speaker 1: Okay, So it's a spec needs a library exactly.
Speaker 2: And what's clever is how it extends JXRS, Java's RES technology.
Speaker 2: It's built on jxrs.
Speaker 1: Ah, so it leverages RES right.
Speaker 2: That makes it lean, gives it a concise style, and
Speaker 2: it means it plays really nicely with ajx out of
Speaker 2: the box. Because it's already using JXRS for handling requests.
Speaker 1: That JXRS connection seems key. Does that feed into the
Speaker 1: pros and cons?
Speaker 2: Definitely? The pros well. Being closer to HTT means potentially
Speaker 2: less memory overhead compared to some component based framework that
Speaker 2: build big UI trees in memory like JSF Maybe potentially, Yeah,
Speaker 2: it can have a smaller footprint. Plus being part of
Speaker 2: the Jakarta EE spec means reliability, maintenance, community support, okay, stability,
Speaker 2: and if you've used older frameworks like struts, the action
Speaker 2: based approach of Java MBC will feel pretty familiar.
Speaker 1: Makes sense.
Speaker 2: What about the downsides, Well, it doesn't totally hide HGTP.
Speaker 2: You still need some awareness of requests response as.
Speaker 1: Headers, so not quite as much abstraction.
Speaker 2: Right, and it doesn't typically offer two way data binding
Speaker 2: out of the box. If a user types in a
Speaker 2: form you the developer usually need to write code in
Speaker 2: the controller to explicitly update the model.
Speaker 1: Ah okay, so a more manual work there compared to
Speaker 1: some other frameworks.
Speaker 2: Potentially, Yes, it's a trade off more control, maybe a
Speaker 2: bit more boilerplate. In some cases. It's about balancing that
Speaker 2: abstraction versus control over HTTP.
Speaker 1: So when would that extra control be a real advantage
Speaker 1: and when might it just be extra work?
Speaker 2: Great point. You benefit most when you need really fine
Speaker 2: grain control over the HTTP request response. Maybe you're building
Speaker 2: complex rest APIs that also serve htmail pages or highly
Speaker 2: optimize micro services. The flexibility is powerful. Then the drawback
Speaker 2: if you just want something super high level where the
Speaker 2: framework does almost everything automatically. Maybe for simpler cru'd apps.
Speaker 2: It depends on the project control versus speeded development.
Speaker 1: Sometimes that makes a lot of sense. Okay, let's talk
Speaker 1: about the foundation. Java NVC doesn't just run anywhere, right,
Speaker 1: It needs that Java Enterprise Edition Server environment Java EE
Speaker 1: or Jakarta E.
Speaker 2: Absolutely, it relies on that infrastructure.
Speaker 1: And Java itself. Well, it's been the go to for
Speaker 1: enterprise apps, for ages, stability, database connections, talking to other systems,
Speaker 1: handling complex logic. It's built for that scale and just
Speaker 1: for context. Java started with Sun, went through j to EE,
Speaker 1: then JG and now Jakarta E under the Eclipse Foundation.
Speaker 1: We're focusing on Jakarta E eight and Java eight features
Speaker 1: here right.
Speaker 2: And the key is that Jakarta E provides this whole
Speaker 2: ecosystem Java MVC plugs into. It's not standalone.
Speaker 1: What are the key pieces it relies on Well.
Speaker 2: JXRS, as we said, innovational, then JPA, the Java Persistence
Speaker 2: API for database access handles all the tricky SQL stuff.
Speaker 1: Usually OHRM right, Object relational mapping.
Speaker 2: Exactly and critically CDI context and dependency injection. That's how
Speaker 2: Java MVC manages beans their life cycles. It's core.
Speaker 1: CDI sounds important.
Speaker 2: It is plus being validation for data integrity and for learning.
Speaker 2: The book recommends GlassFish Server version five point one, open source,
Speaker 2: free group.
Speaker 1: Of development, and you can manage GlassFish different ways.
Speaker 2: Yeah, command line, a Sadman, WEBGUI, even Arrest API pretty flexible.
Speaker 1: Okay, foundation set. Let's dive back into the MVC components,
Speaker 1: but specifically the Java MVC way, starting with the model
Speaker 1: and that CDI thing you mentioned.
Speaker 2: Right, So Java MVC uses CDI two point zero to
Speaker 2: manage your model classes. Yeah, you typically don't do new
Speaker 2: my model. CDI handles creating and providing instances.
Speaker 1: How does it know which classes to manage?
Speaker 2: Usually annotate them. The simplest is that named You put
Speaker 2: it named on your Java being, say your book class,
Speaker 2: and CDI takes over makes it available to your views.
Speaker 1: Okay, annotation magic pretty much.
Speaker 2: And CDI manages the lifespan of these objects through scopes.
Speaker 1: This is really important to the copes, like how long the
Speaker 1: data lasts exactly.
Speaker 2: There's request scope, a new instance for every single HTTP
Speaker 2: request lives only for that request response cycle. Good perfect
Speaker 2: for temporary stuff like the data submitted in a form.
Speaker 2: Then session scope, the instance sticks around for the user's
Speaker 2: entire browser session. Great for things like user login information, shopping.
Speaker 1: Cards, data that needs to persist across pages for one
Speaker 1: user precisely.
Speaker 2: Then there's redirect scope. This one's need. It supports that
Speaker 2: post redirect get pattern.
Speaker 1: Ah to stop double form submission exactly.
Speaker 2: The object lives across the post request and the following
Speaker 2: get t redirect super useful.
Speaker 1: It definitely needed that before.
Speaker 2: Oh yeah, there's also application scope for data shared across
Speaker 2: all users living until the app stops, and dependent scope
Speaker 2: the default, which just inherits the scope of whatever injects it.
Speaker 1: Lots of options. What if you need something really simple.
Speaker 2: For quick things, there's a built in Javacs dot mvc
Speaker 2: dot model's object you can inject into your controller. Just
Speaker 2: add key value pairs to it and they're available in
Speaker 2: the view. No need for a dedicated class.
Speaker 1: Sometimes handy for simple cases. Okay, so CDI managed the
Speaker 1: model data in its life, Now how do we show
Speaker 1: it the view?
Speaker 2: Right? The view layer. Java MVC mainly uses two templating
Speaker 2: technologies here, JSPS, Java server pages and facelets.
Speaker 1: JSPS are the older ones, right.
Speaker 2: Yeah, classic. You mix HTML with dynamic bits the modern way,
Speaker 2: and what the source recommends is using expression language el
Speaker 2: that syntax.
Speaker 1: Like dumb butt title exactly.
Speaker 2: Access is your CDI beans cleanly. You should also use
Speaker 2: JSDL tags like CT ORH for loops set to different conditions.
Speaker 2: Avoid embedding raw javascriptlets percent jsps. If you can keep
Speaker 2: logic out of the view, keep it clean definitely, and
Speaker 2: the source really advises against using implicit objects like param
Speaker 2: directly in the view that mixes controller responsibilities with presentation.
Speaker 2: Bad idea, Got it?
Speaker 1: What about facelts.
Speaker 2: Facelits is newer xmail based came from the JSF world
Speaker 2: Livesten webi nfus. Its strength is templating reasonable layouts using
Speaker 2: tags like EI dot composition, uid, define, UI dot insert
Speaker 2: really good for consistent page structure.
Speaker 1: Sounds powerful any catches yes, a.
Speaker 2: Big one for Java MBC. While facelts is great for templates.
Speaker 2: You should avoid mixing in actual JSF components or using
Speaker 2: JSS specific expression language. Why is that paradigm mismatch? JSF
Speaker 2: has its own life cycling component model. Trying to shoehorn
Speaker 2: that into Java mvc's request driven model can cause weird
Speaker 2: issues in instability. Stick to facelets for templating, use standard
Speaker 2: EEL for data access in Java mvc.
Speaker 1: Okay, noted, keep JSF stuff out of Java mvc.
Speaker 2: Facelts Right now, the controller, how do you make one annotations?
Speaker 1: Again?
Speaker 2: You bet at controller on the class, usually paired with
Speaker 2: at path to define the base URL like at path books.
Speaker 1: Okay, and methods handle requests YEP.
Speaker 2: For a get request, say to show a list of books.
Speaker 2: A method might return a string the name of the
Speaker 2: JSP or Facebook file like booklist dot jsp simple, or
Speaker 2: for more control, it can return a response object that
Speaker 2: lets you set h GDP status codes, headers, cookies explicitly.
Speaker 1: Ah more power there, and.
Speaker 2: The final URL path is built up application path class
Speaker 2: at path method at path all cancatenated makes sense.
Speaker 1: How does the controller prepared data for the view?
Speaker 2: It injects the needed CDI beans the model objects using
Speaker 2: it inject that, it calls methods on them, sets values
Speaker 2: whatever is needed before the view gets rendered.
Speaker 1: Okay, and post requests like.
Speaker 2: Forms handled similarly, but you use annotations like at form
Speaker 2: paarent book title within the method arguments to grab the
Speaker 2: submitted data directly.
Speaker 1: Okay, that covers the core components. What about making is
Speaker 1: more robust handling user input validation crucial stuff?
Speaker 2: So you capture data from forms or query parameters. Now
Speaker 2: what if the user types letters into a number field
Speaker 2: or leave something blank.
Speaker 1: Errors happen?
Speaker 2: Right? Java MBC uses binding result. You audit as a
Speaker 2: parameter to your controller method. It automatically catches conversion errors
Speaker 2: or validation failures, and then you can check binding result
Speaker 2: for errors. If there are any. You typically add the
Speaker 2: air messages to the model's object and return to the
Speaker 2: same view showing the user what went wrong.
Speaker 1: Nice keeps them on the form.
Speaker 2: Exactly and being validation makes this even better. You put
Speaker 2: annotations right on your controller method parameters or on your
Speaker 2: model bean fields at notinal at size and five at
Speaker 2: pattern Reex built in rules loads of them, and you
Speaker 2: can create custom ones too. Plus you can easily internationalize
Speaker 2: the error messages using validation messages dot properties files, so
Speaker 2: error messages appear in the user's language.
Speaker 1: Very professional. Okay, what about state you mentioned sessions earlier.
Speaker 2: Yeah, persisting state. HTTP is stateless, but web apps aren't.
Speaker 2: We need to remember things about a user between requests.
Speaker 2: HTTP session is the standard.
Speaker 1: Javaway managed by the server YEP.
Speaker 2: Usually via cookies behind the scenes. Java MBC makes this
Speaker 2: easy with at session scope CDI beans. Just inject your
Speaker 2: ad session scope user preferences being and its data sticks
Speaker 2: around for that user. Session. Seems convenient, it is, but
Speaker 2: big caveat. Don't stuff everything into the session, especially large
Speaker 2: objects or lots of data per user. If you have
Speaker 2: thousands of users.
Speaker 1: Online, memory usage explodes exactly.
Speaker 2: It can kill your server's performance and stability. Use session
Speaker 2: scope judiciously only for data that truly needs to persist
Speaker 2: for the session duration.
Speaker 1: Good warning. What about making the UI more dynamic? You
Speaker 1: mentioned AJX.
Speaker 2: Right AGX asynchronous JavaScript in XML, though nowadays it's off
Speaker 2: in JSON not XML. The idea is the browser uses
Speaker 2: JavaScript to make background requests to the server without a
Speaker 2: full page reload.
Speaker 1: Smoother experience, much smoother.
Speaker 2: Mber Is like jQuery made this easier, but modern JavaScript
Speaker 2: has fetch api built in Your Java mvc controller can
Speaker 2: handle these AJAX requests. Instead of returning a full page name,
Speaker 2: it might return just an h T Mel fragment or
Speaker 2: maybe Jason data.
Speaker 1: Okay, so the controller can serve both full pages and
Speaker 1: AJX snippets.
Speaker 2: Absolutely. The JavaScript on the front end then takes that
Speaker 2: response and updates just the relevant part of the page,
Speaker 2: maybe updates account, refreshes, a list, shows a status message.
Speaker 1: Very cool. You also mentioned observers.
Speaker 2: Yeah, CD observers. This is a really elegant way to
Speaker 2: handle cross cutting concerns, things like logging, performance monitoring, security checks.
Speaker 2: Stuff that needs to happen in response to events, but
Speaker 2: isn't core business logic.
Speaker 1: How does it work.
Speaker 2: You create a method in a cdibing and annotate it
Speaker 2: with at observes. You specify the event type you're interested in,
Speaker 2: like maybe an event fired just before a controller method
Speaker 2: runs bore controller event from javax dobc dot event ah.
Speaker 1: So it listens for specific points in the process.
Speaker 2: Exactly when that event happens, automatically calls your observer method.
Speaker 2: It keeps that logging or monitoring code completely separate from
Speaker 2: your controller logic. Really improves maintainability.
Speaker 1: That separation of concerns again seems to be a running theme.
Speaker 2: It's the theme of good architecture really, which brings us
Speaker 2: to bigger enterprise integration like databases.
Speaker 1: Right, how does Java MBC talk to a database JPA.
Speaker 2: YEP JPA, Java persistence API the standard way in Jakarta EE.
Speaker 2: It abstracts away most of the raw sequel uses orim
Speaker 2: object relational mapping.
Speaker 1: So your Java book object maps to a books table precisely.
Speaker 2: You define this mapping using annotations at entity table at
Speaker 2: iocolumn right on your Java class and you can figure
Speaker 2: the database connection details in a persistence dot XML file.
Speaker 1: And how do you actually interact with the data through.
Speaker 2: The entity manager. You inject it, and it has methods
Speaker 2: like find, persist, merge, remove. It handles translating those calls
Speaker 2: into SQL. You'll also need to set up a database
Speaker 2: like apatchy Derby and can figure a data source in
Speaker 2: glass Fish okay.
Speaker 1: So JPA handles the database mapping and interaction. What about
Speaker 1: EJBs Enterprise Java beans EJBs.
Speaker 2: Are components for business logic. They run in a container
Speaker 2: that provides services like transactions, security, concurrency management automatically.
Speaker 1: More than just plan Java objects right.
Speaker 2: There are different types, mainly session EJBs. Stateless ones are common.
Speaker 2: They don't hold client specific state between calls. Good for
Speaker 2: service operations like processing a book rental okay. Stateful EJBs
Speaker 2: do maintain state across multiple calls from the same client.
Speaker 2: Useful for multi step processes like a Wizard or complex
Speaker 2: checkout Singleton. EJBs ensure only one instance exists for the
Speaker 2: whole application. Good for cases or coordinating tasks.
Speaker 1: How does your MBC controller use an EJB?
Speaker 2: Usually just inject it Using an EJB, the container handles
Speaker 2: providing the instance. EJBs also have cool features like at
Speaker 2: asynchronous for background tasks and its schedule for time, jobs.
Speaker 1: Powerful stuff and managing all this complexity, Logging must be vital.
Speaker 2: Absolutely critical, and enterprise apps for debugging, auditing, just understanding
Speaker 2: what's going on. GlassFish uses the standard JSR forty seven
Speaker 2: logging API.
Speaker 1: By default, where did the logs go?
Speaker 2: Typically to server dot log. You have different levels severe warning, info, fine,
Speaker 2: finer finance. You configure the level to control how much
Speaker 2: detail you get.
Speaker 1: Can you use other logging frameworks?
Speaker 2: Yes. Log forg is a very popular, powerful alternative. It
Speaker 2: separates the logging API from the implementation, can reload its
Speaker 2: configuration without restarting the server. Lots of advantages. You can
Speaker 2: integrate at server wide or just for your application.
Speaker 1: Choosing the right logging level seems important.
Speaker 2: It is too little, you can't debug too much. It
Speaker 2: impacts performance. You need a strategy. What stands out here
Speaker 2: is just how essential good logging is for maintaining complex systems.
Speaker 1: Definitely so bringing it all together, this book club example
Speaker 1: really uses all these pieces.
Speaker 2: Doesn't it. It really does. It uses Derby as the
Speaker 2: database configured in glass Fish. It has internationalization for messages,
Speaker 2: It uses APA entities for member book rental. It uses
Speaker 2: stateless EJBs as data access objects baos to handle the database.
Speaker 1: Operations, okay, EJB's for the data logic.
Speaker 2: Then it has simple CDI beans acting as the model
Speaker 2: for the views. A central Java MVC controller manages all
Speaker 2: the web interactions, and the views are jsps using fragments
Speaker 2: and some JavaScript for those dynamic updates.
Speaker 1: It's quite a good demonstration of how these seemingly separate
Speaker 1: technologies MBC, CDI, JPA, EJB all integrate cleanly within the
Speaker 1: Jakarta E platform.
Speaker 2: Exactly. You see how a complex system gets built from
Speaker 2: these well defined modular parts.
Speaker 1: Okay, well, that feels like a pretty third journey through
Speaker 1: Java Mvc one point zero. We started with the basic
Speaker 1: MBC pattern, looked at Java NBC specifics under JSR three
Speaker 1: seventy one, touched on its Jakarta E foundations.
Speaker 2: Cover the component's model with CDI scopes, view a JSP
Speaker 2: and facelooks, caveats, controller handling requests right.
Speaker 1: And then validations, state management with sessions, AJAX observers, integrating
Speaker 1: with JPA databases and EJBs, and finally logging strategies.
Speaker 2: A comprehensive look.
Speaker 1: So hopefully you now have a really solid grasp of
Speaker 1: how Java NBC works and how you can use it
Speaker 1: to build robust, scalable, maintainable applications, web cloud, micro services,
Speaker 1: the lot.
Speaker 2: And maybe this raises an important question for you, the listener,
Speaker 2: to think about as patterns evolve, How does understanding something
Speaker 2: foundational like MVC help you adapt?
Speaker 1: Hmmm, good question.
Speaker 2: Think about how these core ideas, separation of concerns, defined
Speaker 2: roles for data logic presentation might show up even in
Speaker 2: newer frameworks, maybe just with different names or syntax. How
Speaker 2: does this foundation empower you? What stands out to you
Speaker 2: about how these architectural patterns really help developers build better software.
Speaker 1: That's fantastic thought to leave things on something to definitely
Speaker 1: mull over. Thank you so much for joining us on
Speaker 1: this deep dive. We hope you found it valuable.