2 added 221 characters in body
source | link

I have read a lot of posts about putting the logic into the models, but people seems to still save their updated model "outside" the model which results in code as above, where you notify about the change outside the model.

Yep, that is how MVC works. The model is supposed to be a dumb container with no behavior. All that injection you're doing, and adding methods for persistence, that is outside the pattern.

Why keep models behaviorless? Two big reasons come to mind.

  1. Model binding, data annotations, and scaffolding can be used to automatically populate models from the HTTP request (e.g. form/post variables). The model binders won't know about your updateTitle method, they will just set the Title. Heaven help you if you then use that same model as a domain object in a repository update-- it'll be populated with values from the request, not the data store, and you may end up with unforeseen data integrity problems.

  2. Unit testing is much easier with behaviorless models because they form a layer of isolation between controller and view. What's more, it's a layer that does not need to be shimmed, stubbed, or mocked (because it has no behavior). That is why models don't normally have interfaces. Now you are going to need an interface for each and every model, so that you can stub them in your unit tests.

If your scheme somehow offsets the benefits of the normal MVC pattern, by all means, go ahead. Personally I would urge you to consider designing your site with behaviorless models. Keep the persistence logic in the controller (and its dependencies) where it belongs.

I have read a lot of posts about putting the logic into the models, but people seems to still save their updated model "outside" the model which results in code as above, where you notify about the change outside the model.

Yep, that is how MVC works. The model is supposed to be a dumb container with no behavior. All that injection you're doing, and adding methods for persistence, that is outside the pattern.

Why keep models behaviorless? Two big reasons come to mind.

  1. Model binding, data annotations, and scaffolding can be used to automatically populate models from the HTTP request (e.g. form/post variables). The model binders won't know about your updateTitle method, they will just set the Title.

  2. Unit testing is much easier with behaviorless models because they form a layer of isolation between controller and view. What's more, it's a layer that does not need to be shimmed, stubbed, or mocked (because it has no behavior). That is why models don't normally have interfaces. Now you are going to need an interface for each and every model, so that you can stub them in your unit tests.

If your scheme somehow offsets the benefits of the normal MVC pattern, by all means, go ahead. Personally I would urge you to consider designing your site with behaviorless models. Keep the persistence logic in the controller (and its dependencies) where it belongs.

I have read a lot of posts about putting the logic into the models, but people seems to still save their updated model "outside" the model which results in code as above, where you notify about the change outside the model.

Yep, that is how MVC works. The model is supposed to be a dumb container with no behavior. All that injection you're doing, and adding methods for persistence, that is outside the pattern.

Why keep models behaviorless? Two big reasons come to mind.

  1. Model binding, data annotations, and scaffolding can be used to automatically populate models from the HTTP request (e.g. form/post variables). The model binders won't know about your updateTitle method, they will just set the Title. Heaven help you if you then use that same model as a domain object in a repository update-- it'll be populated with values from the request, not the data store, and you may end up with unforeseen data integrity problems.

  2. Unit testing is much easier with behaviorless models because they form a layer of isolation between controller and view. What's more, it's a layer that does not need to be shimmed, stubbed, or mocked (because it has no behavior). That is why models don't normally have interfaces. Now you are going to need an interface for each and every model, so that you can stub them in your unit tests.

If your scheme somehow offsets the benefits of the normal MVC pattern, by all means, go ahead. Personally I would urge you to consider designing your site with behaviorless models. Keep the persistence logic in the controller (and its dependencies) where it belongs.

1
source | link

I have read a lot of posts about putting the logic into the models, but people seems to still save their updated model "outside" the model which results in code as above, where you notify about the change outside the model.

Yep, that is how MVC works. The model is supposed to be a dumb container with no behavior. All that injection you're doing, and adding methods for persistence, that is outside the pattern.

Why keep models behaviorless? Two big reasons come to mind.

  1. Model binding, data annotations, and scaffolding can be used to automatically populate models from the HTTP request (e.g. form/post variables). The model binders won't know about your updateTitle method, they will just set the Title.

  2. Unit testing is much easier with behaviorless models because they form a layer of isolation between controller and view. What's more, it's a layer that does not need to be shimmed, stubbed, or mocked (because it has no behavior). That is why models don't normally have interfaces. Now you are going to need an interface for each and every model, so that you can stub them in your unit tests.

If your scheme somehow offsets the benefits of the normal MVC pattern, by all means, go ahead. Personally I would urge you to consider designing your site with behaviorless models. Keep the persistence logic in the controller (and its dependencies) where it belongs.