3 ms·

I find that web frameworks focus so much on CRUD and not enough on business logic. We usually end up with either fat models or fat controllers, neither of which

I find that web frameworks focus so much on CRUD and not enough on business logic. We usually end up with either fat models or fat controllers, neither of which is ideal or practical. Symfony2 (php), however, offers something they call Services, which I've been using to fulfill the role of the OP's Interactors and so far I'm pleased.

arms 14y ago
I second this. Symfony2's use of Services is refreshing, and I feel that having been made aware of this practice, I now write better software. While reading the article, I kept thinking "this sounds just like a Service class."
thom 14y ago
I sometimes find the contrary though, that some developers can be very reluctant to acknowledge that a particular problem calls for a CRUD app, and they instead spend countless hours 'domain modelling' when there's really no problem domain beyond 'some text we can edit'.
deleted 14y ago
[deleted]
brown9-2 14y ago
What is preventing you from creating a layer of "services" or whatever-you-want-to-call-it in between the controllers and the models in those web frameworks?
- arms 14y ago
  I don't think there's anything preventing you from using Services in other (PHP) frameworks, it's just that Symfony2's Dependency Injection Container component makes it very simple and straight-forward. I think it'd be trivial for other PHP 5.3 compatible frameworks to adopt this component to facilitate using Services themselves.
Jarred 14y ago
I prefer fat models to fat controllers because methods in the controller are much more difficult to reuse than in the model. When models get too fat, I usually create modules that break up the bulk of the model into smaller chunks. Meaning, for example, if it has lots of validations, then maybe I'll move those validations over to a module and then extend/include the module back into the model. I haven't needed to use these modules in any other class, but less code in one place is usually easier to read than more code. If the language you're using isn't Ruby, then a module is basically a means of doing multi-inheritance. Note though -- I didn't read the article

arms 14y ago

I second this. Symfony2's use of Services is refreshing, and I feel that having been made aware of this practice, I now write better software. While reading the article, I kept thinking "this sounds just like a Service class."

thom 14y ago

I sometimes find the contrary though, that some developers can be very reluctant to acknowledge that a particular problem calls for a CRUD app, and they instead spend countless hours 'domain modelling' when there's really no problem domain beyond 'some text we can edit'.

deleted 14y ago

[deleted]

brown9-2 14y ago

What is preventing you from creating a layer of "services" or whatever-you-want-to-call-it in between the controllers and the models in those web frameworks?

arms 14y ago
I don't think there's anything preventing you from using Services in other (PHP) frameworks, it's just that Symfony2's Dependency Injection Container component makes it very simple and straight-forward. I think it'd be trivial for other PHP 5.3 compatible frameworks to adopt this component to facilitate using Services themselves.

Jarred 14y ago

I prefer fat models to fat controllers because methods in the controller are much more difficult to reuse than in the model. When models get too fat, I usually create modules that break up the bulk of the model into smaller chunks. Meaning, for example, if it has lots of validations, then maybe I'll move those validations over to a module and then extend/include the module back into the model. I haven't needed to use these modules in any other class, but less code in one place is usually easier to read than more code. If the language you're using isn't Ruby, then a module is basically a means of doing multi-inheritance. Note though -- I didn't read the article