The problem with controllers • Hacker News Board

Re: The problem with controllers

#21

Post by saurik » Tue, May 08, 2012, 9:25 PM UTC

karmajunkie wrote: post #18

papsosouid wrote: post #15

Earlier quoted context omitted.

It is part of the application, and thus part of the domain. A class that is responsible for getting status updates from facebook is part of your model. The way you say "updates your user model" makes it seem like you are thinking about the model as modelling the database. You keep saying this "has no business being in the model", but you haven't supported that in any way. Why doesn't it belong in the model?

[HN is weird. wouldn't let me post on this earlier, and I was moving it to your post now when you replied.] Its not a part of your application. You have to connect to facebook over a network to get to it. That data is very clearly NOT a part of your application. Now if a facebook profile is actually a part of your domain in some way, you're going to have a class specifically to manage that. Connecting to the network…

[For future reference, you often cannot reply to a post very soon after it is posted from the tree view, but if you click "link" you will be able to reply from the page that zooms in on just that one post.]

As I describe in more detail in my other post, but will put more succinctly and from a different standpoint here: you are confusing the conversation by treating "model" vs. "domain" as if they were equivalent concerns (then to rely on arguments that things outside the domain must be outside the model), while the (possibly quite valuable) school of thought you are invoking puts the "domain" as only part of the model and defines other components that happily include your connections to external state.

Re: The problem with controllers

#22

Post by karmajunkie » Tue, May 08, 2012, 10:31 PM UTC

saurik wrote: post #21

karmajunkie wrote: post #18

Earlier quoted context omitted.

[HN is weird. wouldn't let me post on this earlier, and I was moving it to your post now when you replied.] Its not a part of your application. You have to connect to facebook over a network to get to it. That data is very clearly NOT a part of your application. Now if a facebook profile is actually a part of your domain in some way, you're going to have a class specifically to manage that. Connecting to the network…

[For future reference, you often cannot reply to a post very soon after it is posted from the tree view, but if you click "link" you will be able to reply from the page that zooms in on just that one post.] As I describe in more detail in my other post, but will put more succinctly and from a different standpoint here: you are confusing the conversation by treating "model" vs. "domain" as if they were equivalent conc…

Fair enough—i've been using model in the same sense that Rails tends to, which is to say AR models. All the same, if we're going to use 'model' to refer to any number of classes dealing with application logic (regardless of whether its domain logic) then I return to my earlier argument that the Facebook connection example definitely lies outside the domain (and should also lie outside any AR models used) and that it should belong in a service class used by the application logic. I think we're talking in the same direction but terminology is getting in the way.

Re: The problem with controllers

#23

Post by kastephens » Wed, May 09, 2012, 3:16 PM UTC

The problem isn't controllers. Controller are responsible for mediating the behavior presented to external actors, not defining complex "business" logic.

Complex logic interacts with complex object graphs, not individual models. Therefore, complex logic does not belong in models or controllers (or views). Complex logic belongs in instantated objects (not modules) that represent complex logic. This style may also be known as the "Strategy" Design Pattern.

Strategy objects can have state during their activities, this is why they should be instantiated.

Strategy objects simplify testing because they can be connected with any object graph that presents the same interfaces as the target object graphs.

This leads to interchangable Strategy objects that represent generic behavior which can be applied to actual, simulated or speculative object graphs.