3 ms·

The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching faceb

The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching facebook for a status update, for example, is not domain logic and doesn't belong in a model. And while I agree that we should be modeling the domain, not the database, I think its clear from working on a lot of complex and legacy applications over the last several years rails developers model what the database allows, not the actual domain, thanks to the widespread acceptance of ActiveRecord as the only tool in that toolchest. I'm in 100% agreement WRT to MVC—Rails' idea of MVC was never really MVC as MVC was originally envisioned.

papsosouid 15y ago
I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of the domain and should absolutely be in the models.
- karmajunkie 15y ago
  Oh, i disagree with that completely. A user having a status is domain logic. Pulling that status from an external dependency is decidedly not.
  - endersshadow 15y ago
    How is it not? What draws the line between domain logic and non-domain logic? It would seem to me that, by definition, anything your application does would fall into that application's domain, right? What other domain would it be in? Where would you put a request to a third party for supplemental data, if not in the models?
    - karmajunkie 15y ago
      If it were part of your domain, it'd be part of your application. Connection to facebook by definition is outside the scope of your domain. You can take a couple of different strategies to it, but in general the best way to handle that is to introduce a class whose responsibility is to connect to facebook and return a status (generally speaking, a Service) and something like a Command or Job that accesses the FacebookService and updates your user model. Part of the problem with speaking about domains here (aside from being nonspecific about something that is by its very nature quite specific) is that Rails has an extraordinariliy half-assed approach to domain oriented design (I don't want to use 'DDD' here just to avoid buzzwords). Developers have been told for years to just push it into the model because all the work belongs there, but that's BS. a LOT of the work has no business being there.
      - papsosouid 15y ago
        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?
        karmajunkie 15y ago
        [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 to update that still isn't a part of that class's responsibility. Look at it this way: if there were someone who knew everything about your problem area, would their knowledge of the behavior of the data include reaching out to facebook and pulling it in over a network connection? almost certainly not, unless your domain is that of a browser. If your domain is something like klout, for example, your domain is going to include concepts like profiles, connections, posts, etc. Its not going to include anything involving Net::HTTP.
        saurik 15y ago
        [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.
  - strictfp 15y ago
    I like to think of the problem like this: Imagine building another interface to your app. Take a CLI as an example. Should the 'facebook update' feature be activated if you use your app through the CLI? If the answer is yes, it belongs to the model. If no, it does not.
fusiongyro 15y ago
> Rails' idea of MVC was never really MVC as MVC was originally envisioned. It's worth noting that as originally envisioned, the controller directly dealt with the keyboard and mouse. I would argue that not only is Rails not MVC as originally envisioned, something that reanimated the original controller would probably suck. MVC as done in Cocoa on the other hand, is really good. Stock, reusable controllers that simply mediate communication between models and views. If any MVC-style web framework had something like this, it would be pretty amazing.

papsosouid 15y ago

I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of the domain and should absolutely be in the models.

karmajunkie 15y ago
Oh, i disagree with that completely. A user having a status is domain logic. Pulling that status from an external dependency is decidedly not.
- endersshadow 15y ago
  How is it not? What draws the line between domain logic and non-domain logic? It would seem to me that, by definition, anything your application does would fall into that application's domain, right? What other domain would it be in? Where would you put a request to a third party for supplemental data, if not in the models?
  - karmajunkie 15y ago
    If it were part of your domain, it'd be part of your application. Connection to facebook by definition is outside the scope of your domain. You can take a couple of different strategies to it, but in general the best way to handle that is to introduce a class whose responsibility is to connect to facebook and return a status (generally speaking, a Service) and something like a Command or Job that accesses the FacebookService and updates your user model. Part of the problem with speaking about domains here (aside from being nonspecific about something that is by its very nature quite specific) is that Rails has an extraordinariliy half-assed approach to domain oriented design (I don't want to use 'DDD' here just to avoid buzzwords). Developers have been told for years to just push it into the model because all the work belongs there, but that's BS. a LOT of the work has no business being there.
    - papsosouid 15y ago
      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?
      - karmajunkie 15y ago
        [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 to update that still isn't a part of that class's responsibility. Look at it this way: if there were someone who knew everything about your problem area, would their knowledge of the behavior of the data include reaching out to facebook and pulling it in over a network connection? almost certainly not, unless your domain is that of a browser. If your domain is something like klout, for example, your domain is going to include concepts like profiles, connections, posts, etc. Its not going to include anything involving Net::HTTP.
        saurik 15y ago
        [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.
- strictfp 15y ago
  I like to think of the problem like this: Imagine building another interface to your app. Take a CLI as an example. Should the 'facebook update' feature be activated if you use your app through the CLI? If the answer is yes, it belongs to the model. If no, it does not.

fusiongyro 15y ago

> Rails' idea of MVC was never really MVC as MVC was originally envisioned. It's worth noting that as originally envisioned, the controller directly dealt with the keyboard and mouse. I would argue that not only is Rails not MVC as originally envisioned, something that reanimated the original controller would probably suck. MVC as done in Cocoa on the other hand, is really good. Stock, reusable controllers that simply mediate communication between models and views. If any MVC-style web framework had something like this, it would be pretty amazing.