Clean Separation of Concerns in MVC

Baby names search - Search for Liviu

Baby names search - Search for Liviu — Sat, 12 Sep 2009 07:07:38 GMT

Pingback from Baby names search - Search for Liviu

Baby name meaning and origin for Melvyn

Baby name meaning and origin for Melvyn — Tue, 28 Jul 2009 05:37:44 GMT

Pingback from Baby name meaning and origin for Melvyn

ASP.NET MVC Codeplex Preview 5

Melvyn Harbour — Fri, 29 Aug 2008 09:01:22 GMT

ASP.NET MVC Codeplex preview 5 went live last night. Available here . I haven't had a dig into it yet

re: Clean Separation of Concerns in MVC

liviu — Thu, 07 Aug 2008 15:56:20 GMT

Hi, i've read your posts on asp.net mvc forum. I think the problem that you state is valid but the place where the logic of converting the values should stay is not the view. More, I think that the ViewData itself should be responsible for this. ViewData should know how to serialize itself inside the rendered http form. The input controls, if they are non standard should modify the serialized data and not participate in the form postback. The controller would instantiate the ViewData instance from the HttpRequest, so the controller would be agnostic. the view also would be agnostic, if it will use some sort of generic javascript generated by the ViewData serialization itself.

I may sound confused, but english is not my native languge...

re: Clean Separation of Concerns in MVC

MelvynHarbour — Thu, 31 Jul 2008 15:22:54 GMT

I think the controller is basically fairly implicitly coupled to HTTP. It's a web framework after all. The big problem I think is the number of situations from where a request may have originated. Yes, in a lot of situations, there's going to be a view which can return to the same view for some sort of conversion to higher level objects, but that isn't always going to be the case.

Here's a scenario that I believe puts a spanner in your works. What if I have a link somewhere on my site (or indeed someone else's!) that is a GET query and supplies several parameters that will be routed to a controller within my application. There is clearly no View that this has originated from (particularly if it's on someone else's site), so it's going to have to be able to deal with a name/value collection. The parameters being passed could quite easily be dates (blog posts by month?). And I think this is quite a common scenario. It's clearly going to be ridiculous to write an action method so that it will respond appropriately to both strongly typed and weakly typed data, so we have two choices. If we go down the strongly typed route, I think it basically means we have to give up the ability to have hyperlinks that cause GET queries to be run. Which would be a shame!

re: Clean Separation of Concerns in MVC

ceilidhboy — Thu, 31 Jul 2008 15:10:18 GMT

"It's the view's problem to conform to the contract of what the controller requires..."

Agreed. The last thing a controller requires is a NameValueCollection populated with values from fields on the view. This is equivalent from the business logic getting a NameValueCollection from a DAL populated from fields in a table instead of a DAO.

The HTTP contract is between browser and view layer. The contract between controller and view shouldn't be at the level of HTTP.

In this whole discussion, both here and in the ASP.NET forums, no-one has yet given me any argument against my proposal of having the view convert the NameValueCollection back to a higher-level object.

IOW, given the choice between the controller dealing with a high-level object or a NameValueCollection from fields on the view, which would you choose?

As for unit testing, how are you going to test the controller? Mock an HttpContext, Request and Form NameValueCollection? That still implies that it's coupled to HTTP. Your previous thoughts suggest you don't want the controller coupled to that. Why not instead mock something that can convert from the NameValueCollection into something abstract and have the controller deal with that?

re: Clean Separation of Concerns in MVC

MelvynHarbour — Thu, 31 Jul 2008 08:37:10 GMT

As stated in the thread that inspired this post, isn't it the case though that we could think of the contract as having been defined by the controller. The fact that the controller's outputs (perhaps a strongly typed business object) aren't the same as the inputs (a mixture of method variables and HTTP request variables), but I'm not sure that's a problem. It's the view's problem to conform to the contract of what the controller requires.

The problem I think is how to 'define' the HTTP contract. I'm not sure there's a good solution to this. Perhaps the way round it is to (in some way) consider the unit tests to be the 'contract' - you have defined in the code you wrote for them the HTTP request parameters that the controller expects. The View would need to match these. A bit bizarre, I'll grant you, but still not the end of the world.

re: Clean Separation of Concerns in MVC

ceilidhboy — Wed, 30 Jul 2008 22:05:02 GMT

I think you're not differentiating between two forms of coupling. When you talk about controllers knowing about view and/or model classes, it's one thing for them to be aware of the classes and talk to their public interfaces.

But it's another kind of coupling entirely for one class to rely on the internal behaviour, i.e. the implementation, of another class.

It's not a question of the controller having to know that the view exists and call on it. It's a question of the controller having implicit knowledge of the implementation of the view and depending on that to function.

To refer back to your post title, the view is concerned with transforming a model object (assuming we're using ViewPage<T>) into HTML output. It should also therefore be concerned with transforming it back again when the form is submitted. The view doesn't have to submit back to itself. It just needs to provide the service to convert the NameValueCollection back again.

An analogy is encryption. You can call an encryption class to encrypt output. You'd expect to call that same class to decrypt it again. The crypto class is merely performing a service. Something in the view layer should perform a similar service - in both directions.

Clean Separation of Concerns in MVC

DotNetKicks.com — Wed, 30 Jul 2008 15:57:39 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Clean Separation of Concerns in MVC

cibrax — Wed, 30 Jul 2008 13:38:13 GMT

Hi, If the controllers are decoupled enough from the views to make unit tests against them, it is ok to me. That is the main purpose of the MVC framework. I think it is not so important to archieve a complete separation of concern.

Regards,

Pablo