This week's book giveaway is in the Programmer Certification forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 and have Jeanne Boyarsky & Scott Selikoff on-line!
See this thread for details.
Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

How to change normal code into mvc?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, is there any "easy" way to remake code into mvc? I did a little program but I need to make it in MVC style. I dont really know how this supposed to work, I watched some tutorials but it didnt give me much. The main problem is that i have functions that have prints and some math and as I understood I need to separate them, print into view and math into controller?
pastebin
 
Marshal
Posts: 66266
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Please post the relevant information here; many people are reluctant to open links like that. Maybe a UML diagram would suffice in he first instance.
Why did you say, “normal”? Don't go thinking that MVC code is somehow abnormal.
 
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MVC - Model/View/Controller is an architecture where you separate the 3 concerns of GUI operation. The Model is the data. The View is the visual display itself, consisting of some sort of window, web page, or other visual media containing controls (text boxes, radio buttons, checkboxes, action buttons, and so forth).

Controllers link Models and Views. When data changes in the Model, the Controller updates its corresponding value in the View. And when a user changes a control's data value in the View, the Controller updates the Model.

Note that there doesn't have to be a strict one-to-one correspondence. A single Model might have 2 Controllers, each of which updates a separate View. My favorite example of that is a table that renders in one View as a spreadsheet and in another View as a Pie Chart display.

Generally, the platform you are working on will provide MVC support. For example, Java Swing has a whole raft of stuff. Web frameworks like JavaServer Faces don't even need you to code your own Controllers, because JSF has them built in.

On the other hand, if you've tried doing a GUI by brute force without MVC, then you'll have some major re-architecting to do to make it MVC, since you'll need to move functions to the appropriate lobe of the MVC architecture. And there's no easy way to do that, since every do-it-yourself GUI has its own peculiarities.

Overall, however, MVC is a better way to manage GUI. The parts are well-defined, so maintenance and debugging is simpler. You don't have to go on a "treasure hunt" to find which part of your code needs work, since you'll have a clear idea of what's doing what.
 
Thomas Dlonias
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So i made some changes and end up with this, could you please see if this looks like mvc or something like mvc?
BEFORE: https://pastebin.com/kxTAs7S1
AFTER:
model: pastebin
view:  https://pastebin.com/H8b20TER
controller: https://pastebin.com/BXuY1tZQ
run: https://pastebin.com/zE4KBzLv
 
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't get past model but I would say "No" because your model class still has output statements sprinkled all over it. The point of MVC is to separate representation of state (Model) from presentation (View) from flow control and coordination (Controller). Your model still contains behavior that should be in the View component.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Additionally, this method in the View is also a misplaced responsibility.

That looks like it's logic that should be in the Controller instead.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And your controller class hardly has any logic at all. It does nothing that suggests it's controlling the flow of information from one layer of the app to another.

It seems you need to first have a firm grasp of what exactly each part of MVC is responsible for doing. This code you shared unfortunately indicates that you don't quite understand how those responsibilities are to be distributed between the Model, View, and Controller.
 
Tim Holloway
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One other thing. Actually MVC by itself is pretty useless. Usually, MVC is used to manage a GUI data entry/control system, but the real work (business logic) is not part of MVC.

The Model is (ideally) nothing but data and the accessor (get/set) methods used to query and update it. In other words a POJO with no logical functions in it.

The View is often generated automatically from a View Template. Although not, alas, in Swing, where you have to construct it the hard way.

The Controller methods do absolutely nothing but notice changes in Model or View and transfer those changes to their counterparts.

So all you're really doing in pure MVC is shuttling data back and forth.

In the Real World, however, you might want to retrieve a record from a database, edit it, and store the changes. In such cases, an external business method would fetch the data, construct a Model, View and Controller, allow editing, and then the "OK/Save" button on the View would trigger an event (usually via some sort of action listener) that tells the business function to save the results from the current state of the Model, and then destroy Model, View and Controller.

Details may vary. In JSF, for example, the listener for an action is typically a method in the Model bean, although that's just the jump-off point to possibly more complex logic in actual business logic and/or persistence beans. Indeed, many people mistakenly think that a JSF backing bean is a Controller - which it isn't. Ever. As I mentioned previously, all the Controllers in JSF are pre-supplied. In JSF you only code Models (backing beans) and View Templates. Unless you are very advanced and creating a custom JSF tag, and that's something few other than the external tag library vendors such as RichFaces, IceFaces and PrimeFaces do.

Speaking of Controllers in the plural form, I should also note that often MVC elements exist as a directed acyclic graph (tree). For example, a Dialog Window might contain multiple panes, a pane might contain a set of text boxes or radio buttons, and some controls, such as combo boxes might even be treated as having View components within a larger component- one for the textbox part and one for the dropdown list.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:The Model is (ideally) nothing but data and the accessor (get/set) methods used to query and update it. In other words a POJO with no logical functions in it.


You are perhaps thinking of the View-Model in MVVM

In Domain-Driven Design, a model that contains only data and get/set methods is an antipattern (see Anaemic Domain Model) and what you describe are referred to as Data Transfer Objects.

As designers, there are a few variations of MVC that we should be aware of, such as MVP. Each has their own way of apportioning responsibility to the different layers. We should not think these patterns describe the whole application architecture, however. Things like persistence and other infrastructure concerns would be in different layers and are also important to consider but they're not part of these MV(whatever) class of architectural patterns.

As with most design decisions, deciding which of these patterns to use comes down to making reasonable tradeoffs and seeing which fits best for your particular context. Sometimes the technology you're using can be a key deciding factor and can actually lead to favoring one pattern over others.
 
Tim Holloway
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:
You are perhaps thinking of the View-Model in MVVM


No, actually, I was thinking of the abstract MVC architecture as I first encountered it in the SmallTalk system, which is, as far as I know, the primary progenitor for MVC today.

Junilu Lacar wrote:
In Domain-Driven Design, a model that contains only data and get/set methods is an antipattern (see Anaemic Domain Model) and what you describe are referred to as Data Transfer Objects.


No on several counts.

1) I didn't postulate an abstraction of View Rendering and processing, although in fact, JSF does do that. Not that anyone ever used it.

2) Anæmic Domail Model as an "antipattern" flatly offends me. JPA Entity objects absolutely should not contain any sort of business or presentation logic and they are a very viable - and important - part of modern Enterprise Java. Are they supposed to be an antipattern, then?

3) I prefer DTO to refer to things that actually are Transfer Objects. There is no obligation that part or even all of an MVC model be transmitted in bulk to any other subsystem. You could, for example, present an application's run options for live editing as a Model. In JSF, I often use a Façade object as the UI Model for a JPA Entity, thanks the the fact that JPA checkboxes only work with binary properties and certain databases lacking true boolean column types.

Beyond that, I really wasn't interested in the quirks of individual MVC implementations. What I was trying to point out was the abstract concept behind all of them, whether it's the relatively pure MVC of JSF or the Model2 architecture of Struts. Specifics can give false impressions. If one understands their common underpinnings then it's easier to understand specific implementations and to reduce confusion when moving between them.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:
2) Anæmic Domail Model as an "antipattern" flatly offends me. JPA Entity objects absolutely should not contain any sort of business or presentation logic and they are a very viable - and important - part of modern Enterprise Java. Are they supposed to be an antipattern, then?


You're taking that out of context. I clearly wrote "In Domain Driven Design... is an antipattern (see Anaemic Domain Model)" -- There are arguments for using the kind of objects you describe as domain objects but that's an entirely different design approach. I tend to favor the rich domain objects myself but that's probably because I gravitate towards architectures that come out of the DDD way of designing. I don't think your choosing otherwise necessarily invalidates your choices. Everyone's mileage may vary. No need to take things that personal.
 
Tim Holloway
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm afraid I'm not familiar with Domain Driven Design. I don't even understand the DDDCommunity definition, to be honest. In the kind of apps I like to work on there are ioften multiple "domains", but I don't think I'm using the term in the same way they are. So pardon me if I missed the subtlety of being a discipline-specific anti-pattern. I read it as an absolute anti-pattern, and per my example, I couldn't accept that.

I do tend to think in abstract terms. I've had a long and very evil career doing many things on many platforms, often at the same time, and determining the bases and commonalities of things is one of the ways I manage to rapidly develop expertise on new platforms. Also, it means that I don't think of what a platform "does" allow, but what it "should", and if I design for things that aren't yet there, well, I can usually make a pretty good approximation until the platform catches up to me.

You did highlight something interesting, though. MVC in its abstract form says nothing about how things are done. Controllers are pretty straightforward, since they merely shuttle data back and forth, but the View and the View Realizer are actually 2 different sins under one cover. From the developer's point of, er, view, the View is simply a target. But Views often have intelligent controls and layout managers. Generally there's some sort of framework that supports that. As far back as Macintosh Resource Editor days, and more recently Android and JSF (to name 2), it's often been possible to template a View and depend on non-developer resources (sometimes the OS itself) to deal with that stuff, but sometimes, again, Swing, AWT, and SWT being good examples, one has to do all or part of the View Management oneself.

Android is a really good example, since you can use templates or do the entire application UI via application logic.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:No, actually, I was thinking of the abstract MVC architecture as I first encountered it in the SmallTalk system, which is, as far as I know, the primary progenitor for MVC today.


Yes, MVC came out of SmallTalk and Tryvge Reenskaug's work at Xerox Parc. I've actually met Tryvge, who is Jim Coplien's mentor (not that it's germane to this discussion). I wonder what his thoughts are regarding the kind of domain model objects you described. I've read about Naked Objects which are also related to Reenskaug's MVC work (I think) and Eric Evans' DDD work. I have to go AFK right now though but I'd be interested in finding some references that would shed light on what the originator of MVC himself thinks of Rich vs Anaemic Domain Models.
 
Tim Holloway
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I worked once with a DIY ORM that put some of the View Rendering logic into the "Entity" classes, and it was a royal nightmare. I ended up parallel-coding JPA Entities and migrating. So I'll take the bloodless ones, since it was my blood that was being shed.

Extensive work with JSF also taught me to be very aware of the distinction between ORM Domain Model and UI Domain Model. In JSF you can - to a limited extent - share the two, since both are POJOs. But not always. As I said, stuff like how an ORM sees a boolean field and how JSF needs it sometimes requires a separation. And since JSF is absolutely ignorant of persistence, it cannot present a fetched Entity as a Managed Bean. But I've found a very effective set of design disciplines to make it all work smoothly, so I'm pretty happy.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Well, I worked once with a DIY ORM that put some of the View Rendering logic into the "Entity" classes, and it was a royal nightmare.


Just that little bit does sound like a nightmare. I don't think that's the idea behind rich domain models though. I suspect we're just not aligned on terms. In DDD, Data Transfer Objects have a very specific responsibility of ferrying information between Views and Rich Domain Model objects. Anyway, like I said before, YMMV and real-world realities and imperfections have to be dealt with pragmatically.
 
Tim Holloway
Saloon Keeper
Posts: 21271
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It was more than a nightmare, because they'd also implemented a custom UI and it didn't scale, and couldn't handle transactions spanning multiple tables. And I do a LOT of work with "working sets" - graphs of Entities from different tables. I actually devote an entire layer of my standard app architecture to that. It's also the layer where database business logic happens, separate from the DAO layer which is mainly just the finder and CRUD functions per-table.

To me, a DTO is the thing that the presentation layer of an app used to pass back and forth stuff from EJBs, since that's how Sun originally listed in in their JEE patterns roster. EJB3/JPA essentially eliminated the need for them, since in EJB, a "DTO" is simply the detached version of an Entity. A scratchpad copy used as an MVC Model doesn't rate quite the same to me, but I nit-pick a lot.

Actually, using JPA in webapps, everything above my persistence Service layer is detached. So when I save the results of an edit, the modified set of detached Entities is merged in the Service layer (which makes them sort-of DTOs), but if I cancel the edit, I simply discard the modified working set. Less overhead that way.
 
and POOF! You're gone! But look, this tiny ad is still here:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!