4 ms·

Sorry, but data-bound events are not useless in server context. It might be exactly what we need when fat controllers go out of control. Perhaps you meant they

by pestaa 14y ago

Sorry, but data-bound events are not useless in server context. It might be exactly what we need when fat controllers go out of control. Perhaps you meant they are too much of a complication if taken too far to work across all concurrent requests? Binding data and behavior together breaks the rule of single responsibility, which I believe is far worse than designing separate roles in sepearate components that work together. Models should model the data structure only, if you need a presentation abstraction anyway for multi-model operations. Why not go the extra mile and use this abstraction level for all operations? It is a false dichotomy that you go either full-OOP or purely functionaly. Models wrap knowledge as the article suggests, That means that, in addition to getters and setters, they might contain functions that let you check "is this the user's password?". I envision these methods to work on a single attribute, whereas multi-attribute and multi-model business logic belongs to operations. MVC isn't dead, but it was a local maximum OOP gave us. Event-driven development seems to raise and work well with objects and datasets.

alttab 14y ago
If "fat controllers go out of control" then you've already made multiple mistakes. I don't think re-inventing the wheel is the right approach to fixing a problem when the developer can understand their own mistakes instead of blaming a framework or architecture. Are you suggesting that OOP breaks the rule of single responsibility? Any 'operation' that modifies the internal data should belong on the model. Would turnLeft() belong on a Car model? Or do you pass a Car into a turnLeft operation? In my mind a turnLeft operation shouldn't know the details of how to turn a car left, or a bike left, or a boat left. These operations belong in the Car, Bike, and Boat.
- drone 14y ago
  Somewhat pedantic, but just throwing this out there: cars, bikes, and boats are all forms of transportation which can turn. They should probably inherit the concept of turning left, and then specify the exact meaning in their context. Obviously, I don't say "turn your handlebars such that the left side is closer to your chest," or "rotate your steering wheel counter-clockwise," when I mean to tell someone to turn left at the next intersection. I might, however, tell a sailor to steer to port at the next buoy. =) EDIT: forgot to say, fwiw, that I agree that such actions do not belong in the model. The things go in the model, and the only actions the model should support are those relative managing the data in the model, not interacting with the data... That is, after all, what the controller is for.
  - alttab 14y ago
    Im having a time parsing what you mean. Are you saying a car should not turn left, and that a controller should turn the wheel left? Please clarify
    - drone 14y ago
      ... it was a roundabout way of explaining how right you were, or at least in my initial reading of it. I see thing which is called a Car, an instance of which is stored in the Model, which may contain other things, including other types of Transports. The user interacts with the View, instructing a left turn - the controller grabs the Car (why it grabs the Car, and not the Bike is undefined =), and tells it to turn left. None of the M, V, or C understand what a left turn is - but the controller knows that the Car can perform such a thing if instructed. The Controller knows it can tell the Car to turn, because the Car is descended from a Transport, and all Transports have a virtual method for turning. That last sentence was in my head and unfortunately took over my comment.
      - alttab 14y ago
        Ah I understand. Yes polymorphism in this case would hide the details, and the implementation for turning the car belongs inside of that object.
  - einhverfr 14y ago
    I dunno about the last part. I think any logic inherently tied to the data should be in the model. The controller shouldn't have to worry about internals of the model any more than necessary. Here's an example. Suppose I create an i18n framework for handling numbers. I certainly am going to include in it a function for converting the number into the current user's localized format, and another one for converting the number from the current user's localized format. I will probably also have functions to convert to/from db formats and to/from arbitrary formats. Not all of these will be called by the controller (in most cases, just the ones to/from the user's localized format and maybe an arbitrary format on rare occasions). This way the controller script can just call something like $number->to_output; and get the localized string back. Other model objects can call $number->to_db and get a string suitable for entry into the db. Interestingly in LedgerSMB 1.4 where we have done this, the number of cases where the model calls number i18n functions are remarkably small. These are usually called in the model or in the view simply because the controller probably shouldn't have to worry about this, and the view gets to worry about display logic.

by pestaa 14y ago

alttab 14y ago

If "fat controllers go out of control" then you've already made multiple mistakes. I don't think re-inventing the wheel is the right approach to fixing a problem when the developer can understand their own mistakes instead of blaming a framework or architecture. Are you suggesting that OOP breaks the rule of single responsibility? Any 'operation' that modifies the internal data should belong on the model. Would turnLeft() belong on a Car model? Or do you pass a Car into a turnLeft operation? In my mind a turnLeft operation shouldn't know the details of how to turn a car left, or a bike left, or a boat left. These operations belong in the Car, Bike, and Boat.

drone 14y ago
Somewhat pedantic, but just throwing this out there: cars, bikes, and boats are all forms of transportation which can turn. They should probably inherit the concept of turning left, and then specify the exact meaning in their context. Obviously, I don't say "turn your handlebars such that the left side is closer to your chest," or "rotate your steering wheel counter-clockwise," when I mean to tell someone to turn left at the next intersection. I might, however, tell a sailor to steer to port at the next buoy. =) EDIT: forgot to say, fwiw, that I agree that such actions do not belong in the model. The things go in the model, and the only actions the model should support are those relative managing the data in the model, not interacting with the data... That is, after all, what the controller is for.
- alttab 14y ago
  Im having a time parsing what you mean. Are you saying a car should not turn left, and that a controller should turn the wheel left? Please clarify
  - drone 14y ago
    ... it was a roundabout way of explaining how right you were, or at least in my initial reading of it. I see thing which is called a Car, an instance of which is stored in the Model, which may contain other things, including other types of Transports. The user interacts with the View, instructing a left turn - the controller grabs the Car (why it grabs the Car, and not the Bike is undefined =), and tells it to turn left. None of the M, V, or C understand what a left turn is - but the controller knows that the Car can perform such a thing if instructed. The Controller knows it can tell the Car to turn, because the Car is descended from a Transport, and all Transports have a virtual method for turning. That last sentence was in my head and unfortunately took over my comment.
    - alttab 14y ago
      Ah I understand. Yes polymorphism in this case would hide the details, and the implementation for turning the car belongs inside of that object.
- einhverfr 14y ago
  I dunno about the last part. I think any logic inherently tied to the data should be in the model. The controller shouldn't have to worry about internals of the model any more than necessary. Here's an example. Suppose I create an i18n framework for handling numbers. I certainly am going to include in it a function for converting the number into the current user's localized format, and another one for converting the number from the current user's localized format. I will probably also have functions to convert to/from db formats and to/from arbitrary formats. Not all of these will be called by the controller (in most cases, just the ones to/from the user's localized format and maybe an arbitrary format on rare occasions). This way the controller script can just call something like $number->to_output; and get the localized string back. Other model objects can call $number->to_db and get a string suitable for entry into the db. Interestingly in LedgerSMB 1.4 where we have done this, the number of cases where the model calls number i18n functions are remarkably small. These are usually called in the model or in the view simply because the controller probably shouldn't have to worry about this, and the view gets to worry about display logic.