21–30 of 72 posts
This replaces the controller with classes for each action, a Service? Then responders are automatically called and they do renders. Sounds nice, would be fine with it as a default, but not sure it warrants doing a big change for me.
First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them modular. They can only be modular if the author actually implements them in a modular way (and you can do that in Rails today).
The DI-framework can't handle change at all:
class CurrentUserResolver
def initialize(user_finder = User)
@user_finder = user_finder
end
# note that resolvers themselves get injected
def call(session)
@user_finder.find_by_id(session[:current_user_id])
end
end
And then there's the added complexity. Now I need to keep track of the route-mapping, default policy, route policies, the route service and the route renderer. Which are now in several different files. And there's not even a clean class-to-file mapping to help me locate it.
Oh, and the premise of testability. Well, this makes it very easy to test units itself, but the more you split your projects into smaller units, the more bugs occur when you mix the units. Sure, you can get your precious fast test runs (and a nice green test), but in reality you're only testing a single unit of a complected app.
EDIT: This reminds my of Rick Hickey's quote from keynote at RailsConf2012:
""We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.""
Earlier quoted context omitted.
> Is not instantiation etc a cross-cutting concern that violates SRP in this instance? Right. Which is why hes also recommending the use of DI. It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start…
> It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter. The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a har…
Sure. I wasn't saying otherwise. What I meant was, in a general sense (prior to really seeing the benefits first hand), it can be hard for people to justify the trade off when they feel like they can just "get it done faster" with a more ad-hoc approach to things. I didn't mean to imply Objectify was some how more difficult (I haven't used it, so I wouldn't dare comment on it in such a way).
>I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).
Agree to disagree, with a caveat. I'm not against having a large amount of "Helper" or in the case of what I'm most familiar with, "Extension" classes (godbless you, .NET Extension classes), but I think if you have so many that they comprise most of your code base, maybe you could consolidate some of them (and maybe you couldn't).
Personally, I try to keep 100% of my core business logic inside of "Service" style classes, and then anything that is more of a helper (in that it performs some work, but not "business logic", and does not require or alter internal state) in either a static helper, or an Extension on the type itself.
For example, I usually end up adding a .ToStart/EndOfDay/Week/Month suite of methods to the datetime object of most of my projects. A "DateTime Service" would be overkill, but an extension method (which is just veneer over a static helper) fits the model perfectly, in that it returns a new copy of the existing datetime, leaving the original intact.
But at this point we're getting pretty deep into the comment tree, so feel free to email me from my profile if you want to go more into the issue - I love shooting the shit over this kind of stuff. Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.
Probably worth bringing up Steve Yegge's 2006 "Execution in the Kingdom of the Nouns": http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain ex…
This idea of having an ubiquitous domain language and keeping applications and APIs RESTful have been two of the most beneficial ideas I've incorporated into my development in recent years.
Having said this, I respect the attempt, the problem it tries to solve certainly does exist to some extent, and the solution cannot be completely dismissed very easily.
But please, please, do learn both A) basic history and B) basic theory of the field you are working in. If you try to reinvent everything you decrease your chances of contributing something new manyfold.
This is not object-oriented at all, unless you learned about object-orientation from Java and its monster frameworks, this is basically a form of data-flow programming. OO is about message passing, here the "objects" do not pass any messages at all, the supposed "objects" _are_ the messages, and the routing of those messages takes place in the configuration in routes.rb, so the objects do almost no message-passing be…
Wrong. I'm hearing this more and more, but let's be clear: Active Record as a design pattern, before Rails, has always been a joining of business logic and persistence. (http://martinfowler.com/eaaCatalog/activeRecord.html) It's always been in violation of the single responsibility principle. If you want to avoid that, don't use Active Record! Use a Data Mapper, which specifically separates Mappers and Finders from Domain model classes. (http://martinfowler.com/eaaCatalog/dataMapper.html)
I'm not saying you can't move logic out into reusable modules or whatever is being recommended here, but please don't make it out like people are in the wrong when they're using the library or framework the way it was designed to be used.
What is wrong with writing your core application logic physically removed from any of these frameworks. Why do people insist on fitting their application into the Rails framework or any other web framework.
Write your core application code in Ruby (or your language of choice), package it in another gem, use tools and patterns we've had all along to plug that code into a dependency for persistence (if needed)...communicate with it through a standard API that you define for your delivery mechanism (i.e. Rails).
I just don't get this idea of trying to contain my application code within the confines of a specific framework.
"Single responsibility principle (SRP): ... ActiveRecord::Base already has a responsibility: persistence." Wrong. I'm hearing this more and more, but let's be clear: Active Record as a design pattern, before Rails, has always been a joining of business logic and persistence. ( http://martinfowler.com/eaaCatalog/activeRecord.html ) It's always been in violation of the single responsibility principle. If you want to av…