I have almost all of the "shared" statements in functions in my model. The problem is that I am getting the following error, when I need to use more then one of these functions in my controller:
Controller action should call one model method other than an initial
find or new
and the IDE goes deeper explaining that:
This inspection warns if a controller action contains more than one
model method call, after the initial .find or .new. It’s recommended
that you implement all business logic inside the model class, and use
a single method to access it.
Is this mean that all of the logic should be put in more complex model functions? I have thought that the work of the controller is to call model functions and passes the results to the view.
If I put back the model functions code back to the controller, everything will work, but I will get a code duplication in all my controller actions.
So, what is the right approach here?
The warning message indeed means that the logic should be put in a single model function, but not necessarily more complex ones. To avoid model duplication and/or the "fat model" problem, you may need to introduce additional classes that the model relies on.
Yes, the work of the control is to call model functions, but only as a thin veneer, per this inspection guideline of one model function per controller action aside from an initial create/find.
I'm not sure I understand your comment about getting code duplication in your controller if you move functions back up, since you can always introduce shared functions at the controller level. But again, that's not the recommended approach of "thin controller" and "reasonably thin model" with supporting classes as required.
Related
Saying I am writing an action in my controller.
While it has many logics: several if statements, also has cases.
Is there a way that I can group these logics, for instance, I want all the if statements to be in one file and case statements in another file. so in my controller, I do not have to write whole bunch of codes, I can just call the files that contain these statements. Like in HTML we use script tag to include JS files
And maybe other action can also use these files in the future.
Your controller's actions shouldn't contain that volume of business logic. There are many potential solutions:
You can move your logic into your model layer, using model concerns to share logic amongst models
Distill your action's logic into several reusable methods, and move those methods into your ApplicationController so that they can be reused by any controllers that inherit from your ApplicationController.
Introduce a controller concern, containing the relevant logic chunked into methods, and include that concern in the controllers that need access to the logic.
Moving slightly away from the built-in Rails conventions, you can introduce a layer of "service" objects that you can instantiate to hold reusable blobs of business logic that don't necessarily fit into your model layer.
These are often called "services" or "operations", and reside in app/services and app/operations respectively. In terms of code structure, these would be simple classes that accept inputs from your controller, perform complex operations on your model layer, and then make output available to your controller so that it can be rendered to the user.
There is an additional set of Rails conventions defined in a project called TrailBlazer that might be a useful template on which to model your own service/operation layer.
We don't know the exact logic in your controller, but normally is a bad practice to include the logic in it. You should delegate all the business logic in the models.
From your controller you should only handle HTTP related things, and delegate to the correct model.
Assuming that this aproach is not the one for you, you can also use ActiveRecord Concerns, they are very usefull for DRY, allowing you to include little snippets of reutilizable code
If this even doesn't fit your requirements, you can put some .rb files in app_folder/lib, it's usually autoloaded, and you didn't need to require it manually
It would be very useful if you post the code of your controller, that would give us a better vision of what you are trying to do
I'm relatively new to rails, but I've made a few basic CRUD apps. However, this time, I'm making something different, and I'm not sure how to organize it.
It's essentially a one page app. The user fills out a form, and the code does some calculations based on those values. I have all the code written, but it's all just sitting in the controller. I'm assuming that this isn't correct.
There are two parts:
Using an external API, 2 constant arrays are generated. I need these variables to be global, or at least accessible for the calculator function.
I have a function that takes some inputs from the form that also calls other functions. A simplified version is below. I could put all the code into one function if that's necessary. I have them separate just so that the code is more readable.
def calc(input)
func1(input)
func2(input)
# do more stuff
return answer #I need to show this in the view
end
def func1(a)
end
def func2(b)
end
So, where should I put each part of this code?
To make your controllers thin, you can keep business logic at Service Objects.
Just create "services" directory at "app", add there some class like "user_searcher.rb".
And call it in the controller, passing all necessary data.
Such technique will help you to isolate business logic and incapsulate it in separate class.
BTW read this article http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
I think, from what I understand of you question, is this code should be placed in the helper classes. If you have dedicated class for this calculation, you can use class attributes to access array to access anywhere in the class or declare them constant, in case they are constant.
I don't think making global is a good practice, just because this is needed in some other function, instead return that variable and pass them as parameter where they are needed.
In my current project, i notice few thing,
Maximum part of the business logic are moved to helper.
Included all helper files in a module under lib directory and included that module in application controller.
In many methods, no argument passed, instead they used the instance variable(create instance variable in calling method and use that instance variable in the called method).
Each action will call a helper method to execute business logic and that method will call some other helper methods.
All method are written as public, No protected and private method.
Models are used only for validation.
are those points follows good coding conventions? if not, can you suggest me the best coding standard to improve performance?
First, convention has nothing to do per se with performance.
Maximum part of the business logic are moved to helper.
I would say this is very bad. One of the popular idioms is "fat models, skinny controllers", which works most of the time. Put all the business logic you can in your models, where they belong. If you have really complicated views you want to simplify, use decorators (e.g the draper gem), and then separate business logic (model) and view logic (decorators) into their according locations.
Included all helper files in a module under lib directory and included that module in application controller.
Okay I think. As long as you have one place to maintain that chain, it feels okay. If it leads to misunderstandings/misusings/hacking around, then: not okay.
In many methods, no argument passed, instead they used the instance variable
If you're talking about methods in your model: this is good, since the method is targeted at the scope of your instance, and not of your class.
Each action will call a helper method to execute business logic and that method will call some other helper methods.
Sounds strange. The controller is responsible for preparing your data used in the view. If you are preparing specific data in your helpers to assign them to your view for usage, consider putting these into a decorator (as mentioned above). But calling a helper in almost every action sounds like something is done the wrong way.
All method are written as public, No protected and private method.
Non-public methods should not be public. Take a look at helper_method and hide_action from ActionController.
Models are used only for validation.
Wrong. Models contain the business logic, as mentioned above. What about modifying things in the console? Would you want to update all logical related data by hand, then? Do you do this "by hand" in your controller right now (which it seems like) ? What about when you introduce an API, do you copy-paste the code in there to not miss some logic? And what when the logic changes, are you really sure all required endpoints manually and independently handling that logic are also updated?
There's a reason models have relations, callbacks and instance methods. Use them!
Performance is not related to your arguments; they are about project organization.
Maximum part of the business logic are moved to helper
This shouldn't happen, you should move the business (aka models) logic inside the models. Rails doesn't force you doing it, so keeping the logic organization is up to developers.
Models are used only for validation
This is a consequence of putting the business (aka models) logic outside the models. You should move it from the controllers/helpers to the models. Again, Rails doesn't force you to do that, so it's up to developers to do it.
Included all helper files in a module under lib directory and included that module in application controller.
In many methods, no argument passed, instead they used the instance variable(create instance variable in calling method and use that instance variable in the called method).
Each action will call a helper method to execute business logic and that method will call some other helper methods.
All method are written as public, No protected and private method.
I think that these points are (some more, some less) related to the Rails Helper design. One flaw of Rails is the Helper design: they go against the OO pattern and usually end up by being a bunch of unorganized functions, à la PHP.
For this reason some people use Decorators. Decorators "add an OO layer of presentation logic" (from Draper), allowing to organize better the view related methods.
If you want to examine the argument, I suggest you the following links:
Google search about decorators
Draper
The Ruby Toolbox, presenters category
My base controller has:
[Authorize(Roles = "sys_admin")]
I want to have one action in a controller that's different and is available to "user" and "sys_admin". Can I override and how do I do that?
Also any suggestions on what else I could put in a base controller that might make my coding simpler. For example what's in your base controllers?
Anything that you use in every controller - attributes, methods, properties, etc. The same stuff you would put in any base class.
Just to add to the discussion, I have a few extra utility methods in my shared controller. I write a bunch of little apps for corporate use, so I try to repeat code as little as possible here.
getContext(): Puts together an object containing user info like IP, hostname, id, etc. for logging purposes.
Shared Views/Partials such as Error, Default, and Redirect (used for redirecting ajax requests).
RedirectToError(): I created this to use similar to RedirectToAction. I load up an ErrorObject with info, throw it in session, and return a Redirect to my Error page.
General logging and tracing methods so I can quickly spit out information to a file.
I override OnActionExecuting and check if my session is still valid and redirect to login if its not. Probably better with attributes...went with quick and dirty. Also trace Url.PathAndQuery for debugging here.
Any data access actions that I would use across views with ajax, like loading up a list of departments.
OnException is overridden, as well.
That's what I got in mine so far.
In my base controllers I actually put some utility method ([NonAction]) collected over time. I prefer to add functionalities to Controllers by decorating with Attributes if possible.
Lately my base controller has:
some Properties for retrieving information about the current user (my app
specific informations, not the User.Identity stuffs)
A simple protected override void OnException(ExceptionContext
filterContext); override for at least logging unhandled exception and have
some sort of automatic notifications
A bunch of Cookies related methods (WebForms auth cookies management
for example)
A bunch of usefull standard attributes (usually [Authorize], [HandleError], [OutputCache]) in its declaration.
some standard method for preparing widely used json data types on the fly (when possible I prefer to have a standard json object with ErrorCode, ErrorMessage and a UserData).
With time you'll find more and more utilities to keep with your controllers, try to keep an assembly with the simpler ones (avoiding heavy dependencies), will come handy with your next MVC projects. (the same goes for Helpers and to some degree also for EditorTemplates).
For the Authorize Attribute part, well, I think the cleanest way is to write your own AuthorizeAttribute class, specifically a NonAuthorizeAttribute. I think I've also seen it somewhere on SO.
You can also play with the Order Property of the default AuthorizeAttribute - put different Order in BaseController and in Action, in order to have Action's one executed first, but I cannot recall if you can actually break the Attributes processing chain.
Regards,
M.
We cant tell you what you need in your base controller, you have to reveal these kind of thing as you implement your controllers and see repeating code.. Dont hesitate to refactor these things to your BaseController, and keep in mind, that maybe you should have 2 or more BaseControllers, or 2-layer hierarchy of BaseControllers.
I give you two tips, what i always have in my BaseController :
super-useful helper method for interface-based model binding :
protected T Bind<T, U>()
where T : U, new()
where U : class
{
T model = new T();
TryUpdateModel<U>(model);
return model;
}
You can then have multiple "sets" of properties you want to bind in different scenarios implemented as interfaces, and simple model bind your object (even existing object, from DB) with incoming values.
2.If you use custom AcionResults (maybe your specific Json builders etc.), make your "shortcuts" methods in BaseController. Same thing as View() method is shortcut for return new ViewResult(...)
To add more to the good responses already here -
caching caching caching caching
See
Disable browser cache for entire ASP.NET website
i have a function that converts an array to a hash which i would like to use across all the model, controller and view files in the rails app.
Does this violate some core design principle, or am i missing something really obvious?
UPDATE: This is actually a software engineering question. I want to understand why some "convenient" things are not allowed in rails, and i suspect it is precisely because they do not want us to do it
This is likely actually a bad practice. It'd likely be better to instead always work with arrays and hashes in your controllers and models and if necessary convert them in the view to the alternative.
That is, if the data is natively represented as a array throughout your application work with it that way and if required to be a hash in the view either convert it first and assign it or convert it in the view using a helper.
View global helpers go in: helpers/application_helper.rb
If you must call a helper from a controller you can still define it there and I believe you can do:
def Something
....
hashData = #template.helper(arrayData)
end
Calling helpers in a model is REALLY not a good idea, there's no point.
As a final note, encapsulating this logic in a library would likely be ideal, your controllers can call a library & your view helpers can as well.
I think you are: views should not need that method. The controller ought to do it and pass it along to the view for display. The controller or, better yet, service layer might apply that method to a model object, but there's little reason for a model object to know about it.