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 ...
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am looking for an engine that does AI text summarization based on the concept or meaning of the sentence, I looked at open-source projects like (ginger, paraphrase, ace) but they don't do the job.
The way they work is that they try to find synonyms for each word and replace with the current words, this way they generate alot of alternatives to a sentence but the meaning is wrong most of the times.
I have worked with Stanford's engine to do something like highlights to an article and based on that extract the most important sentences, but still this is not abstraction, its extraction.
It would also make sense that the engine I'm looking for learns over time and results are improved after each summary.
Please help out here, your help is greatly appreciated!
I don’t know any open source project which fits your requirements about abstraction and a meaning as I assume.
But I have an ideas how to build such engine and how to train it.
In a few words I think we all keep in mind some Bayesian-network like structure in our minds, with helps us not only to classify some data, but also to form an abstract meaning about text or message.
Since it is impossible to extract all that abstract categories structure from our mind I think it’s better to build mechanism which allow as to reconstruct it step-by-step.
Abstract
The key idea of the proposed solution is in the extraction of meaning of a conversation using approaches which easier in operation with it from an automated computer system. This will allow creating the good level of illusion of real conversation with another person.
Proposed model supports two levels of abstraction:
First of them, less complex level consists in the recognition of groups of words or a single word as a group which related to the category, instance or to the instance attribute.
Instance means instantiation from the general category of the real or abstract subject, object, action, attribute or other kind of instances. As an example – concrete relation between two or more subjects: concrete relations between employer and employee, concrete city and country where it’s situated and so on.
This basic meaning recognition approach allows us to create bot with ability sustain a conversation. This ability based on recognition of basic elements of meaning: categories, instances and instances attributes.
Second, the most complicated method based on scenario recognition and storing them into the conversation context with instances/categories as well as using them for completion some of recognized scenarios.
Related scenarios will be used to complete the next message of the conversation as well as some of scenarios can be used to generate the next message or for recognizing meaning element by using of conditions and by using meaning elements from the context.
Something like that:
Basic classification should be entered manually and with future correction/addition of the teachers.
Words from sentence in conversation and scenarios from sentence can be filled from context
Conversation scenarios/categories can be fulfilled by previously recognized instances or with instances described in future conversation (self-learning)
Pic 1 – word detection/categorization basically flow vision
Pic 2 – general system vision big picture view
Pic 3 - meaning element classification
Pic 4 – basically categories structure could be like that
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 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 8 years ago.
Improve this question
I have seen in some (REST) iOS apps that they use "pure" model object, e.g. "Product", core data object, e.g. "ProductCore", and an object to represent the remote objects e.g. "ProductJSON".
I myself usually also use this architecture, I think it leads to clear separation of concerns. It has also some practical benefits, for example there are situations in which I want to create a model object but not add it to core data yet. Or others where I want to send the models directly to the server and not store them in core data.
On the other side, it consumes more memory and I have to maintain more classes. It's also not necessary for a memory cache as core data has one. Temporary objects (e.g. form data which hasn't been validated yet) can also be deleted without performance issues, as managed objects are only in memory until saved. There are also not portability benefits, as anything that understands Swift/ObjC also understands core data... extensibility can be achieved at least with extensions. Maybe subclassing.
So I was wondering, is there an overall preferred way to setup model clases in applications? In which context does an additional layer with pure model objects make sense, where is it an overkill?
Edit: I don't consider this an "opinion based" question. The optimal architecture can be different depending on the requirements, but which is one better under which circumstances should be able to be determined based on facts.
I am not sure what is meant by a pure object. Here is what I am doing:
Service model represents the data sent to and received from web services, and corresponds to their JSON payloads. I write adapters to map JSON to service models and vice versa.
Entity models represent persistent data. These are the Core Data classes corresponding to my data model, and inherit from NSManagedObject.
View models represent data displayed in a view. Each view has its own view model. This approach maps the view model precisely to the view. An adapter class builds the view model from entity models and/or service models (if the data to be displayed is not persistent). The adapter shapes the data to the view, and does things like formatting dates to simplify the job of the view controller.
A table view cell, for example, might display elements from several entity models. The view model would contain a class representing the data to be displayed in each cell, and the adapter would build one for each cell. Populating the table view cell in the view controller becomes a very simple task of mapping one-to-one between view model and cell fields.
This approach might seem overkill, but I have found it to be extremely effective and worth the effort. It greatly simplifies the code in the view controllers, and makes testing easier.
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 8 years ago.
Improve this question
I'm using Core Data in my app and I have many "categories" of data. Some are smaller and some are bigger, and I thought to divide some of the categories to different entities.
So I wanted to ask, if there are any advantages or disadvanteges to using multiple entities even if not mandatory, and if I should also create an entity for smaller "categories" of data? Thanks!
Here is the rule that I use:
If incorporating data into the entity itself with attributes does not result in excessively repetitive data, I would prefer to add attributes rather than new entities.
This is a subtle tradeoff in which you have to consider
Performance
Complexity of the data model
Code legibility.
If you consider these factors carefully with the guidance above, I am sure you can make good decisions on when to create new entities rather than using attributes.
For example, if you have an entity like Story that has attributes like title, text, date, etc. and would like to add a category, in most cases it would make sense to create a to-one or even to-many relationship to a Category entity rather than using a string attribute. Presumably, there will be hundreds of stories and dozens of categories, and the flexibility to have more than one category is a definite advantage.
On the other hand, if you have an entity Story which is always one of not more than three types, i.e. "report", "analysis" or "opinion", you would be better off with an enum type of attribute rather than a relationship to a new entity.
I'm not overly sure what you mean by categories but, obviously the bigger the entity the more memory your app will take up when you load the entities into your NSManagedObjectContext. However there's no real point splitting entities up into two when you're just going to load them both anyway.
In terms of performance Core Data docs mention that even 10,000 objects is a pretty small database. Just be careful with BLOBs, dont load data you dont need into memory and release data when you can using NSManagedObjectContext's reset method.
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