Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
So from my current understanding associations give classes access to methods which allow them to create relationships with other classes. This gives an inner consistency to the models; but how is this really relevant to the end user? I mean, yeah, the developer can now more easily link to like-classes in a more streamlined way, but couldn't the developer do all that with HTML/JS/View? The methods from association seem overly redundant.
I apologize if my understanding is off or my view of this (pun intended) is overly simplistic, I am just trying to wrap my head around the inner mechanics of this system. Could someone explain the point of associations and the role they play to me? 10+ bonus points if you can explain it using a metaphor or ELI5. Thanks!
EDIT:
I already read the documentation. It says "Associations are a set of macro-like class methods for tying objects together through foreign keys" Which I understand. I just want to understand more concretely exactly what they are for because "tying object together" is very vague and as a newbie it really offers me no real understanding.
"Overly redundant?" Doing the same work in every app would be more redundant.
"Typing objects together" is about as concise as it gets: Except in trivial cases, most data has other, related, different data. Consider a tree-based commenting system.
The site has users.
Users have comments.
Comments have parents (and children).
These are related data. Those relationships are abstracted by Rails via associations.
Yes, of course you could do everything manually, but that's true with any framework.
The point is that there is a lot of duplication regarding associative data.
From a practical perspective: without relationships and associations, you cannot store your data into a database.
Imagine that you are building a blog. Your blog have more than one author.
One author can have many posts, and a post have many comments.
How can you show this data in your blog without associations, or even better,
without knowing which post was made by which author, which comment was made in which post
and so on.
But with associations in rails, if you want to know the author of a post you can simply do:
post = Post.find(:id)
post.author
And if you want to know all the posts made by an author you can:
author = Author.find(:id)
author.posts
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Can someone please explain or point out what are the most common design patterns being used or comes naturally in building a rails app (ie: simple apps with crud and search functionality)?
I mean, Ive been programming in java and used frameworks such as struts, and I was able to apply and identify software patterns such as in creational, structural, and behavioral.
Since I switched to ruby on rails, Ive been trying to understand how can I apply design patterns here....
please explain or point out what are the most common design patterns being used or comes naturally in building a rails app
I'm going to start by pointing out the obvious. What comes naturally is the MVC pattern, around which Ruby on Rails is built.
Other than that, Rails does not enforce any particular design patterns, and actually a common beginner mistake is to clutter your views, controllers and models with a multitude of responsibilities, trying to fit everything into the (very limited) MVC universe.
(This also seems to affect the way we write Gems for Rails, as many popular choices tack on to, and adds DSLs your controllers or models.)
That doesn't mean you are restricted to using just models, views and controllers, however. Anything you can do in Ruby, you can also do in Rails.
The popular use of ActiveRecord with Rails will usually prevent you from having a rich domain model, which can, in turn, limit the number of applicable patterns. In particular when working with your models.
Commonly, you will see a rich taxonomy of simple supporting objects, like service objects, form objects, query objects, policy objects, value objects, etc. All used to encapsulate some perticular behaviour of your application. These objects can implement patterns on their own (for example a decorator object implementing the decorator pattern) or be arranged to form common patterns.
For a simple application, this might be all you need--but you can, and should, make use of design patterns where it makes sense in your Rails application.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm starting a massive project for the first time. I was supposed to be one of the developers on this big project, and all of a sudden, the lead developer and his team backed out of the contract. Now I'm left managing this big project myself with a few junior developers under me and I'm trying to get a firm grasp on how this code should be broken up.
Logically, to me, the code should be broken up by the screens it has. I know that might not be how it SHOULD be done. so tell me, how SHOULD it be done? The app has about 6 screens total. It connects to a server, which maintains data about all other instances of the app on other phones. You could think of it as semi-social. it will also use the camera feature in certain parts, and it will definitely use geolocation. probably geofencing. It will obviously need an API to connect to the server. most likely more APIs than just the 1. I cant say much more about it without breaking an NDA.
So again, my question pertains to how the code should be broken up to make it as efficient as possible. Personally, i'll be doing little coding on the project. probably mostly code reviews, unit testing and planning. Should it have 1 file per screen, and parts that are repeated should have their own classes? should it be MVC? We're talking a 30k line app here, at its best and most efficient. is there a better way to break the code apart than the ways I've listed?
I guess my real question is, does anybody have good suggestions for books that would address my current issue? code clean was suggested, that's a good start. I've already read the mythical man month and code complete but they don't really address my current issue. i need suggestions for books that will help me learn how to structure and plan the creation of large code bases
As I'm sure you know this is a pretty vague question you could write a book answering it. In fact, I would recommend you read one, like Clean Code. But I'll take a stab at a 10,000 foot level overview.
First if you are doing an iPhone app, you will want to use MVC because that is how Apple has setup their frame work. That means each screen will have (at least) a view-controller, possibly a custom view or NIB.
In addition you will want your view controllers pointing to your model (your business objects) and not the other way around. These objects should implement the use cases without any user interface logic. That is what your view-controller and view will be doing.
How do you break apart your use cases? Well, that's highly specific to your program and I won't be able to tell you with a (lot of) details. There isn't a single right answer. But in general you want to isolate each object from other objects as much as possible. If ever object reference ever other object, then you don't really have an OO design, you have a mess. Especially when you are talking about unit tests and TDD. If when you test one part you end up pulling in the whole system, then you are not testing just one small unit, are you?
Really though, get a good book about OO design. It's a large subject that nobody will be able to explain in a SO answer. I think Clean Code is a good start, maybe other people will have other suggestions?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm finding that it's difficult to clearly articulate the specific models I want to create at times - especially as projects get bigger and I have to wrap my head around the relationships between everything.
How do you organize your data and user models? Do you sketch them out on paper? Maybe there's a neat tool online?
Yep, I believe good old pencil and paper are the tools to use for that. Keeping in mind that eventually your models will access the database through an object relational mapper, you should think in relations.
Mostly, it is worthwhile to think in relations first and then figure out names for your models. Consider the following case where you need something that stores the following:
posts need to be stored
comments need to be stored
users have to be stored
Now, before you think about how you name each of these, rather think about how they are related. I find that mostly by doing that, you will choose the right names intuitively:
A post belongs to a user, a user has many posts, a comment belongs to a post, a post has many comments, a user has many comments, a comment belongs to a user.
In this last rather intuitive sentence, you have everything you need: names and relations. Rails supports this intuition because it is so idiomatic.
This is as far as planning databases and models goes - if you have an existing application and need to figure out the models' relations, I recommend using a UML (unified modelling language) gem called railroady, which will automatically create a nice graphical overview of your application's data.
I find visualisation to be a huge help in establishing a data model and working on data flow diagrams etc.. Pencil and paper has never worked for me because I get all neatness obsessed and hate making changes and redoing things, and I also don't want to get distracted by moving little boxes around on a screen to make them look nice as it breaks the "creative flow".
I've used GraphViz http://www.graphviz.org/ for this in the past for a number of reasons.
First, I've worked for a lot of companies too cheap to spend money on any software that might accidentally help software development.
Secondly, the text input is distraction free -- it lets you concentrate on content without the distractions. The text input can also be generated by code, so it's been great for (semi)automatic code and schema visualisation.
Third, the input text can be added to the source code repository and commented and change-tracked.
I recently discovered http://graphviz-dev.appspot.com/ which has made it even easier -- don't forget to click on them ad links.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am trying to create a rails app where each user model can have a single team model and a single stadium model and may compete in a single league. Each team contains players, a single trainer, a single cook etc. and each stadium contains one hotel, one carpark etc..
Understandably, all these players, trainers etc.. are going to affect the team's winning chance and levels of carpark and hotel etc. is going to affect the money earned in a period of time.
The problem (originating from the fact that I am not a programmer at all) is that I can't decide whether all these players, trainers, cooks, hotels, carparks etc. should be separate models or just attributes of team and stadium models. After all, if a user upgrades a hotel from level 1 to 2, the stadium's value may be multiplied by 1.2 for example. But I suppose that for more realistic calculations of match winning conditions (goals, fauls, injuries etc.) it may be more suitable to have separate models. So I know it depends on functions or game mechanics. But since I have no experience inthese areas, I cannot plan the base. Can anyone give suggestions?
Can anyone clarify this issue? I have read many MVC articles but I still have difficulty in understanding MVC.
First of all, this is a question about models only, not about MVC. Here are some thoughts when models are needed (or not):
Is there a primitive (String, Number, Date) value that you want to hold, there is no need for an additional model. So e.g. if you only want to store the stadiums value (whatever that is), there is no need to create a Stadium model for that.
If your possible model has more than one value you want to keep, there will be a need to create an additional model. It looks not natural to keep e.g. stadium_value, stadium_name, stadium_size, ...
If your possible model has not only attributes, but behavior, the natural place to define that behavior (as methods) is the model class. So if you want to calculate e.g. the value of your stadium by combining other attributes of your model, the model Stadium is the natural place for that.
This is all independent from Rails and will be true for all object-based or object-oriented languages.
Addition
It is difficult to decide without your whole knowledge. At the end, we talk about how to retrieve and store model objects from the database, and how to display them in a browser. As long as a possible model object is only a single value (like the trainers name), it is faster, easier to implement and to show in the browser. It breaks at the moment you need more than the trainers name then. So make enough design upfront to have it clear which are real model objects, and react as early as possible when you see that you have missed one.
PS: Without being a programmer at all, you will face a hard time implementing it with Rails ...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I can think of quite a few components that need to be created when authoring a web application. I know it should probably be done incrementally, but I'd like to see what order you usually tackle these tasks in. Layout your usual order of events and some justification.
A few possible components or sections I've thought of:
Stories (i.e. pivotaltracker.com)
Integration tests (Rspec, Cucumber, ...)
Functional tests
Unit Tests
Controllers
Views
Javascript functionality
...
The question is, do you do everything piecemeal? (one story, one integration test, get it passing, move onto the next one, ...) OR complete all of one component first then move onto the next.
I'm a BDDer, so I tend to do outside-in. At a high level that means establishing the project vision first (you'd be amazed how few companies actually do this), identifying other stakeholders and their goals (legal, architecture, etc.) then breaking things down into feature sets, features and stories. A story is the smallest usable piece of code on which we can get feedback, and it may be associated with one or more scenarios. This is what Chris Matts calls "feature injection" - creating features because they are needed to support stakeholder goals and the project vision. I wrote an article about this a while back. I justify this because regardless of how good or well-tested your code is, it won't matter if it's the wrong code in the first place.
Once we have the story and scenarios, I tend to write the UI first, followed by the classes which support it. I wrote a blog post about a real-life example here - we were programming in Java so you might have to do things a bit differently with Rails, but the principles remain. I tend to start writing unit tests when there's actually behaviour to describe - that is, a class behaves differently depending on its context, on what has already happened before. Normally the first class will indeed be the controller, which I tend to populate with static data just to get the UI into shape. I'll write the first unit tests to help me get rid of that static data.
Doing the UI first lets me get feedback from stakeholders early, since it's the UI that the users will be interacting with. I then start with the "happy path" - the thing which lets the users do the most valuable thing - followed by the exceptional cases, validation, etc.
Then I do my best to persuade my PM to let us release our code early, because it's only when the users actually get hold of it to play with that you find out what you really did wrong.