What is the best way to split up a large Rails controller, that is large due to logic (for example a checkout with logic for multiple providers)?
The goal is just to have several files instead of one, without having to add new models
There is no universal way would describe how to organize the code. How to split it is an individual decision.
But I can give some common recommendation. I have dealt with stuff like this and can imagine what you have there. So you might find them useful:
try with small changes
find duplicated code and extract it to methods defined in this
controller first
later you can decide what to do with them, but small changes like that help you to grasp the whole picture
simplify code if it's possible
try to figure out responsibilities of the controller, specifically its actions, that's the final goal
once you clearly understand responsibilities of the code you can start to think how to split it
the split should be made based on responsibility of the code chunks
you can use patterns like form objects, service objects, etc.
Related
I'm new to Rails and I have a question. Everyone says the preferred way of iterating through a table is to capture the data in an instance variable via a Controller, then iterate in the corresponding View.
What if I just did
<% Course.all.each do |course| %>
<!-- displays list of courses -->
<% end %>
I know using instance variables is the preferred way, but is there any reason?
Could I not use instance variables?
Yes. The code, as you've written it, works.
Using instance variables is the preferred way, but is there any reason?
It's really just an agreed design pattern to do avoid making database queries directly in the view.
A principle of MVC frameworks is to have the controller prepare all data for the view, rather than the view directly fetching data at arbitrary points. In the long term, you'll find the latter approach can become messy, un-performant and difficult to maintain.
For example, you might start making the same query multiple times, or run into N+1 problems, or struggle to test the implementation at all (because if logic is all inside the view, the only way to test might be via very complex+expensive feature tests, instead of quick and easy unit tests!) - which can make the implementation fragile and error prone.
But rules are made to be broken, and you can write code like this in rails; just take a word of warning from the past experience of developers who invented MVC frameworks in the first place: This is generally a design pattern to be avoided.
You certainly CAN do this, but it does not mean it is a good idea.
Rails operates as an MVC framework which separates models, views & controllers, which in turn is really an application of the "Separation of Concerns" design principle.
By adding controller responsibilities (fetching data) into view responsibilities (displaying data & interacting with the users), you're making it more difficult for the view code to be reused.
What if you only want to display a subset of courses but not all of them, but using the same format?
What if you want to display a different set of courses depending on who the user is at the moment?
What if you want to paginate the course list because you've got 1,000 courses already?
And so on.
This is really hard to appreciate when you are just starting out but getting into the habit as early as possible will save yourself from unlearning it later down the line.
At the end of the day, these are just conventions, and there is a time and place wherein you can break conventions but just be aware that all these "rule-breaking" might eventually come back and haunt you. That's what we call "technical debt" and as with any kind of debt, the longer you keep it, the harder it is to pay it off.
I have for one customer entity multiple viewmodels depending on the existing views like Create,Update,Get,Delete. These viewmodels share the same properties up to 75% with the entity.
Should I better merge all the customer viewmodels to one big viewmodel?
So I have to map only and always from one entity to one viewmodel and the way back?
Do you see any disadvantage in flexibility for certain scenarios I have not in my mind now?
In the long run, keeping them separate will be better because while the data contained in each ViewModel may be similar or even identical, the intention is different. For example, the Create and Update ViewModels are certainly similar, but have a few important differences. First, the Create view model usually doesn't have the identity of the entity and having it there may be confusing since it doesn't make sense. Second, if the application supports partial updates, the update ViewModel may be a collection of changes to an existing entity, not the entity as a whole.
If you are striving for DRY you can achieve re-usability by means other than sharing the entire ViewModel class. Instead, you can create smaller re-usable components and re-use by composition instead of inheritance. Attempting to coerce a single ViewModel class to fulfill all requirements will be buggy beacause the code is more difficult to reason about. Many times, simple copy & paste gets the job done better than what OOP offers.
On one hand, splitting up the ViewModels as you describe makes your code base really clear, as you can make sure each ViewModel is exactly fit for purpose and has no unnecessary properties. On the other hand, it means that you have more code to maintain - a change to your entity may well mean changes to several ViewModels.
On the other hand, the one big ViewModel approach has basically exactly the opposite pros and cons - less code to maintain, but the ViewModels are less fit for purpose.
There isn't really a right or wrong answer here, you've got too weigh up the pros and cons of each approach and decide what will work best for you.
One sort of halfway approach is to have a single ViewModel for Create/Update, one for Retrieve and one for Delete, as the Create/Update are likely to be very similar.
Another, most OO option for you lies in good old inheritance: define common functionality between actions in one class MyVM and extend it (inherit from it) as you see fit for different actions: MyVMEdit, MyVMDelete, MyVMCreate, `MyVMList'.
This is the best of both worlds: you only maintain things once, and you extend them to fit precisely to every view.
There is no right approach here, since its not a math, any approach you take that gets job done will get the job done :) But ... sometimes we carried away from our roots too far :) its pure good old Object Oriented approach.
If inheritance (or extension) poses any issues (for any reason), you can embed MyVM portion inside every MyVM<Action> model and achieve the same level of abstraction / functionality balance.
As usual - right tool for the right job.
Hope this will help you.
In learning about Core Data, I've noticed how (in Xcode's templates) Apple directly used the query classes inside the view controller. This seems like it is bad MVC (having database access logic directly inside the view controller). Would it make sense to abstract out these kinds of actions to a separate suite of classes that obtain the data from the database and pass it back to the view controller calling it?
EDIT–
So, just to be clear, when I say "kinds of actions", I specifically mean CRUD Operations. Though if you have ideas about other things that a so-called "Model-Controller" would do, I'd be interested in hearing about them.
It's a matter of opinion, and often yes the templates are the most simple form of working example. It's hard to have a template spin out multiple files, for example.
Yes, personally, I generally spin out a separate NSManagedObject subclass. I like to have a _MySubclass object that has all the auto-generated stuff, then have the model actually reference MySubclass which has model-based business logic (you can use mogenerator or other methods to do this too if so inclined). Perhaps thinking of it as "Model-Controllers" and "View-Controllers" is another way of putting it.
This is a very good question and the answer likely depends on your situation. Perhaps architecture purists would insist on separate Model controllers and there are a lot of benefits to this approach. However, sometimes I find myself using Key Values when I'm doing a simple view. When things are more complex, for example, when coding the same Model for the Mac and iOS, having separate Model Controllers will allow you to reuse a lot of code. When you must diverge, Obj C Categories are a very clean way to extend functionality without adding a lot of overhead. I personally favor categories over extensive subclassing.
Since NSFetchedResultsController was released, my model classes are leaner. There are a lot of nuances to this and experience will help you come up with the best solution for your App. I've also found that writing unit tests up front will help you force through issues and validate your design, or send you back to the drawing board :)
Just curious why ManagedObjectContexts should be passed to UIViewControllers when they are created, rather than just grabbing them from a UIApplicationDelegate?
The docs say that this makes your applications more rigid, but I am failing to see the nuances of when to use which pattern.
Thanks!
Imagine that I ask you to do some task, like painting a room. If I just tell you "go paint a room," you'll need to ask me a lot of questions, like:
Which room?
Where's the paint?
Where are the brushes?
Should I use a dropcloth?
In short, you won't be able to complete the task without help from me. If you have to depend on me every time, you won't be a very flexible painter. One way to deal with that problem is for me to give you all the stuff you need at the outset. Instead of "go paint a room," I'll say "please paint room number 348 using this bucket of paint and this brush, and don't bother with a dropcloth." Now, you've got everything you need, and you can get right to work with no further help from me. You're a much more flexible worker because you no longer depend on me.
The same thing applies to view controllers (and objects generally); it's better to give them everything they need than to have them depend on a particular object like the app delegate. It's true not just for managed object contexts, but for any information they need to do their job.
This is mainly because you want to use dependency injection with your UIViewControllers instead of just grabbing everything from UIApplication, this keeps your delegate clean instead of full of reference hacks.
This is also to keep with the MVC pattern:
Model
View Controller (Only for view logic)
Controller (For coordinating between the view and the model)
I tend not to agree with this pattern.
First of all I try to treat Core Data as an implementation detail, and as any implementation detail it should be hidden behind a good facade. The facade is the interfaces I expose for my model objects. For example if I have two model objects; Cource and Student, any cource can have a number of students. I do not want to let the controller take upon the duty to setup predicates and sort descriptors, and jump through all Core Data hoops just to get a list of students for a particular class. There is a perfectly valid way to expose this in the model:
#interface Cource (StudentAccess)
-(NSArray*)studentsStortedByName;
#end
Then implement the ugly stuff once and for all in the Model class. Hiding all the complex details of Core Data, and no need to pass around managed object contexts. But how would I find the sources, it has to start somewhere right? Yes, it does but you need not expose it to the controller. Adding methods such as these are perfectly reasonable as well:
#interface Cource (CourceAccess)
+(Cource*)caurceByID:(NSString*)courceID;
+(NSArray*)allCources;
+(NSArray*)courcesHeldByTeacher:(Teacher*)teacher;
#end
This also helps in minimizing dependencies between controllers. And reducing he dependencies between the model and controller. Assuming I have a CourceViewController and a StudenViewController is I did not hide the Core Data details behind a facade and wanted to pass around the managed object context as well, then I would end up with a designated initializer like this:
-(id)initWithManagedObjectContext:(NSManagedObjectContext*)moc
student:(Student*)student;
Whereas with good a good facade I end up with this:
-(id)initWithStudent:(Student*)student;
Minimizing dependencies behind facades, in favor of dependency injection also makes it much easier to change the internal implementations. Passing around the managed object context encourages each controller to implement their own logic for basic stuff. Take for example studentsSortedByName method. At first it might be sorter by last/first name, if later changed to last/first name sort you would have to go to each and every controller that has sorted students and make the change. Where a good facade method requires you to change in one method, and all controller automagically get the update for free.
The Apple Docs try to foster the most widely applicable and sustainable design patterns.
Dependency injection is preferred because it allows for the most flexible, expandable, reusable and maintainable design.
As apps grow in complexity, using a quasi-singleton like parking the context in the app delegate breaks down. In more complex apps, you may have multiple context tied to multiple stores. You might want the same view-controller/view pair to display data from different context at different times or you may end up with multiple context on different threads/operations. You can't pile all those context up in the app delegate.
If you have a simple app with a single context then using the quasi-singleton with the app delegate can work well. I've used it on several smaller apps in the past without immediate issue but I did hit scalability problems on a couple of apps when the apps grew overtime.
Which pattern to use depends on your shipping constraints and you best guesses about of the evolution app over its entire lifecycle. If its a small one shot app, then the app delegate quasi-singleton will work fine. If the app is more complex, might grow more complex or might spawn other related apps that will reuse existing components, then dependency injection is the way to go.
If I have two tables in a DB User and Userinfo (split for normalisation purposes) I generate the two models User, UserInfo and use them as normal via relationships.
Later on I have section of my application that reads and writes to both, however, there is a fair amount of business logic on creating entries for example looking up other tables for conditional rules, string building etc.
Would it make sense to make a third model (a non-database-backed model) to handle all this and to create/save via the other two models? or should I keep this in the controller?
Another example could be importing a CSV file where all the data is split between different tables, separate models as used by the rest of the application. Could I use a model defining each row that handles saving the imported data via the other models. Or again should this be in the controller?
I am interested in the best practices when developing large rails applications.
Sounds like you're normalizing (minimizing redundancy) rather than de-normalizing.
I don't know your application, so please take this as something to consider rather than a recommended best practice: what I typically like do in a situation like this is hide the Userinfo behind the User, so that the User is the only part of the application that even knows there is a Userinfo. This keeps things simple and consistent and DRY across the other clients of the code (controllers, other models, and you when you interact with it in the console).
Introducing a third model might serve the same purpose, but it's also adding conceptual weight to the application.
The answer depends on why you split the user data into two tables in the first place - what problem was it supposed to solve. Figure that out and try to apply the same logic to the models.
In any case, I agree that it makes sense to create a third model that encapsulates the complexity of working with the other two. This lets you present a simpler interface to other layers of the application (controllers, views). However, you'll have to watch carefully how far you're going with this. If you find yourself re-implementing most of ActiveRecord::Base by delegating calls to your encapsulated components, then it may be time to reconsider.
BTW, what you did isn't de-normalization. De-normalization in the context of a relational database means creating redundancy (check out the Wikipedia article on normalization, de-normalization is the opposite). This is usually done in order to improve performance by reducing the amount of joins required.