Question: Is it good form to Dispatch a signal in a Model "setter" for poor man's Data Binding?

[travisbrownjohn]

Hi, Thanks for all the great work on StrangeIoC so far! I'm part of an experienced dev team looking to make the switch from a proprietary in house engine to Unity, and Strange has really helped inform our architecture decisions.

I'm new to MVC and C# in general but I was wondering if it makes sense to hook a signal to a set method of a Model's property?

private int _score;
public int score 
{ 
   get { return _score; } 
   set 
   { 
       _score = value; 
      updateScoreSignal.Dispatch (_score); 
   } 
}

This seems simpler to me than having to remember call
updateScoreSignal.Dispatch (model.score); everytime I update the Model.score property.

Thoughts?

[NickDiMucci]

My rule of thumb for models has always been to make them as dumb as possible. Objects that wrap values, nothing more. Some frameworks do encourage actual work to occur in the model (Backbone.js is one example that comes to mind), but I don't agree with that.

That said, whether this is a good idea or not, I'm going to say "it depends". If I was working on a project that I knew only I would be touching, then I might do something like this, but given that you're part of a dev team, I would say "don't do this" as it could possibly set a false precedent on what model objects should be doing, and someone else could start making models do a lot more than they should be, and a broken window is created (something that causes a rapid decay of code quality). You have to decide if the convenience is worth the risk of that.

Using a framework like Strange creates a lot of plumbing code to wire things up, but it's for the greater good.

[travisbrownjohn]

Thanks for the feedback.

I feel like with a change like this, code quality goes up. I was able to remove several lines of code sprinkled about various files where the model (score/level/lives) was updated and the corresponding signal needed to be Dispatched.

If the model is truly dumb, then you everyone who ever updates the model has to remember to wire up the signal.

Is there another approach that fits better with MVC(S)?

----- Original Message -----
From: "Nicholas DiMucci" [email protected]
To: "strangeioc/strangerocks" [email protected]
Cc: "travisbrownjohn" [email protected]
Sent: Friday, January 31, 2014 3:31:21 PM
Subject: Re: [strangerocks] Question: Is it good form to Dispatch a signal in a Model "setter" for poor man's Data Binding? (#4)

Normally, models are to be as dumb as possible. Objects that wrap values, nothing more. That said, whether this is a good idea or not, I'm going to say "it depends". Given that you're part of a dev team, I would say "don't do this" as it could possibly set a false precedent on what model objects should be doing, and someone could start making models do a lot more than they should be, and a broken window is created (something that causes a rapid decay of code quality). You have to decide if the convenience is worth the risk of that.

Using a framework like Strange creates a lot of plumbing code to wire things up, but it's for the greater good.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[NickDiMucci]

It depends on the greater context of the project. If there are many spots that this Signal needs to get fired due to the score being set, then you may be right that doing it directly in the setter method is best. Firing a Signal isn't really doing "work" anyways, so I wouldn't feel guilty about doing it ;)

[srimarc]

I pretty much concur with Nicholas. I'd just add that adding a signal to the Model and then to the Model's clients effectively creates an undesirable concrete dependency. So "better" is relative in this respect. Factor that into your decision.

Most important: whatever you do...do it as a team. Avoid the chaos of individual idiosyncrasy.

[travisbrownjohn]

Thanks for your feedback. I'm not sure which way we'll go. Still wrapping my head around all of this.

Thanks so much for the strange rocks project, it has really helped clarify many concepts so far.

[travisbrownjohn]

BTW, is this the correct forum for these types of questions?

[srimarc]

Yep. Just fine. We also have a StrangeIoC Google Group, which would arguably be better if the community grew larger (reserving this space for bugs/feature requests, etc). But with the community we have right now, this is a perfectly sensible place to ask questions.