The Bare Minimum Intro To Service Object & POROs | Ruby On Rails Tutorial

Ya'll take this stuff too seriously. Service objects and Plain Old Ruby Objects (POROs) are just some Ruby classes that do some business logic.
Checkout my course(s) at: learn.deanin.com
Join this channel to help support these videos:
/ @deanin
Follow me on social media:
linktr.ee/deanin
If you liked this video, please consider subscribing: t.co/RZ4EwP0F2a
#Deanin #Software #Programming

[@Deanin]

If you want more than the bare minimum, consider reading this now that you know how to make a service object: www.toptal.com/ruby-on-rails/rails-service-objects-tutorial

[@Deanout]

But Dean, what about what I wanted you to talk about? The cool way to not need to use the new command, or why service objects should only have one public method because I said so? Or or or-

[@Deanin]

Read the link.

[@developerfoe]

coming for next video ...

[@johanandre5338]

I use service objects when the logic does not clearly belong in a specific place (usually a model). Like doing a operation which requires two or more different instances. That logic can sometimes be misplaced in a model. But as you say, it’s only plain ruby classes… ☺️

[@aarona3144]

The amount of shade you're throwing at everyone in this video is hilarious (including that streaming site) 😆. You're right though, a lot of this stuff shouldn't be taken too seriously but I think its a good idea to see what tends to be about one or two best practices like how you're doing here.

[@mertgunduz5571]

Great outro speech Dean 👍

[@ellerium]

Hey, I'm new to your channel, and I need to say I really liked your videos. I've been working with Rails for some time. And really appreciated your way of talking about this concept of service objects. Especially for keeping away all the passionate discussions. I have an honest curiosity I'd like to ask: Did already thought about those service objects as a model? As in the Model-View-Controller design. I'm asking because I understand an ActiveRecord object as a model of a Business Entity. While the service is a model of a Business Process. Does it make sense? Thanks for you videos!

[@iamshairyar]

Quick refreshment course

[@azizdevfull]

very very useful for me bro : )

[@MrThomas8307]

Hi Deanin. Thanks for your useful video. Now maybe you show us how to use "dry-monads" .

[@ledockol]

Thanks! 👍 Rails 7 Search Facets Filters?

[@OjasMutreja]

Hey there, I am unable to the right extensions of VS Code for Ruby on Rails7, could you please guide me

[@merlin2049er]

Put it in the tmp folder

[@freibuis]

not a fan of service objects my self but I would use ThingService.call(object) instead of ThingService.new(object).call the reason why I think the use of call instead of using the method name same as the class name example ThingService.new(object).do_thing is that the class name tells you what its doing. you dont need to tell me twice. nothing wrong with it but my ocd kicks in. I prefer to use model concerns to clean up models.. but some times you might want to pass options and this will break when using model concerns. this is when I would use a service object. lets say 1 model has a counter column called countera and another counterb .. you could do something like IncrementService.call(object, :countera) .. then logic to increment that coloum... This would remove duplicating logic accross models. I personally dont use them. but if a project that I join is using them. I would continue the convention.

[@vinogradova82]

Cool!) If use this like below, then no need to call a new method in controller. Only use inheritance in all yours services. Right?) # app/services/application_service.rb class ApplicationService def self.call(*args, &block) new(*args, &block).call end end