MLB app

Guys, I’m making a baseball league application, and I’m facing some challenges. Biggest of them is trying to make a match simulation method (I didn’t think a view was necessary for it). This method is in matches_controller.rb, but again, there isn’t any view for that. How do you think I should handle it? Have you ever faced any similar trouble?

Git repository:

PS: I love sports at all, so if you have a hockey application to share (it doesn’t have to be written in Rails), please do it

I think you should read as much as possible about Object-Oriented
programming right away :slight_smile:

"Practical Object-Oriented Design in Ruby (POODR)" by Sandi Metz
is a good intro, but there are lots of other resources online.

That "simulate" method does NOT belong in a controller, it belongs
in a model, and I would also recommend you step back and try to
describe the problem(s) you're trying to solve in the form of tests,
breaking the steps down as much as possible. Flowcharting on a
whiteboard or sheet of paper might be useful too.

Good luck!

Hi andre, like hassan is pointing out, your code wil become very needlessly complex pretty soon because you are not separating responsibilities or the classes, the controller is a class that should only be handle handling where to direct the request, not actually performing operations on the data or what ever. If you keep going that route the controller will become a huge procedural app in itself. You should have something like this there[:match_data]).simulate()

And then simulate should hide all that complexity from the controller.

In any case, please explain better the problem you are trying to solve.

First of all, Happy holidays to you folks.
Secondly, I’d like to deeply appreciate the help you’re giving me

Hassan, I’ll search for this material you’ve suggested ^^. But I didn’t understand why this doesn’t belong to the controller (since it’s on the controller), but I hope I can make it clearer at the end of this message. I also have a difficulty on describing my problem as a set of tests, since it’s not completely clear to me the complete set of states of execution my app will go through

Radhames, I couldn’t understand what you tried to tell me there (copying what you said) --> “the controller is a class that should only be handle handling where to direct the request, not actually performing operations on the data or whatever.”

Talking about what I want to do. My long-term goal is to simulate a MLB season game by game (with every kind of play and player). To achieve it, I want to build a method to simulate a match. By now, and as a short-term goal, I want to produce a generic result, and important for me is building a good algorithm not depending on where to build it (controller, model, or helper – it sounds a little freak to me to make on the view (I’m doing it, but I swear it’s just provisory LOL))

In a close future, I want to take the simulation to next level, creating a model for pitchers and batters. But again, it’s something for future steps.

I know I have a long way to go through on learning Rails, but on groups like these, my learning goes faster

Again, thank you, Hassan and Radhames

But I didn't understand why this doesn't belong to the controller

Business logic doesn't belong in controllers, it belongs in models or
service objects. It's accepted good practice and makes testing much
much easier. Reading up on the MVC pattern would probably be a
good thing too.

also have a difficulty on describing my problem as a set of tests, since
it's not completely clear to me the complete set of states of execution my
app will go through

Writing tests is a way to explore the problem space, it doesn't mean
having a completely architected solution first.

Remember that a model does note need to be backed by a database table.
There should not be any significant logic in a view or controller.
It is much easier to test logic (algorithms) if they reside in a model.


@andre the issue is you are trying to dump walls of code (text) in a single file. The complexity of your application will increase a lot, you will have one BIG simulate method that does everything, such big methods are hard to understand after a few weeks even by the developer that wrote them. In general good code is written in a way that hides complexity from the rest of the system, so, what its actually maintainable is to have code that works by hiding complexity. Something like a model, for example, User.first, its nice to use because its hiding the complexity of connecting to the DB, building the query and mapping record into a ruby object, imagine having that code dumped into each model file, wouldnt it make finding your own code or navigating around different part of the code confusing? now imagine dumping that code directly in the controller, having a controller connect to the DB, build the query and handle the edge case and then loading a ruby object with the returned record? that would surely make controllers a mess, instead of having the short methods like

def index

@users = User.all


it would be

def index



you are talking the path of the second example.

So how is this problem solved? there are several best practices, like encapsulation, and limiting responsibility of what you are putting in a file. In Object Oriented Programming we aim at hiding complexity inside classes, think of classes as kitchens, like the ones in cafeterias,

they have a small window, an order comes in on a small piece of paper and a dish comes out, how the dish is made and how many cooks are in the kitchen is not something that customers or waiter should be concern. Your controller is a class, it takes one argument calles the

Request object from rails, that object has the params and session information, the controller uses it to decide if it should respond with success, redirect or deny access. During one of those decisions it might ask a class for a value, and there is a chance that a class is an active record model, but the controller does not know that and does not care where User.first got its value, to the controller its just a ruby object, period. You are trying to change that pattern, you want to make a controller that will calculate a “Simulation” something that might imply a lot of code and needless complexity.

You will have this

def simulate



Instead you should have something like this

def simulate

@simulation =[:home_team]),[away_team]))

if @simulation.valid? # check if the simulation makes sense inside that method and hide everything from the controller

flash[:notice] = "this are the results"


flash[:error] = 'Simulation parameters are invalid'

redirect_to :show