Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2018

Note that nothing said here should be taken as anything other than the ramblings of a madman.

From the apparently fairly seminal doc, Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) by Steve Burbeck, Ph.D.:

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). [emph mine]

I think that does it. MVC means you've got a View (what the viewer sees), the Controller (controlling what happens to a user's input) and a Model (what encapsulates the data itself). I'm going to try to go with that.

It's like 3-tier, but with two one-way roads going from your UI to your data management tier, one for what your app is showing the user, and another one-way road designed for what to do with your user's responses to what they see in the view.

That would make Fowler's image of MVC make more sense:

local copy of image

As well as his explanation of the "missing" line between View and Controller:

Essential dependencies between model, view, and controller. (I call this essential because in fact the view and controller do link to each other directly, but developers mostly don't use this fact.)

Note that the arrows are pointing the right way. The View does ask the Model for data to display. The Model does not push to the view.

That's the first time I've seen MVC described in a way that makes sense, so I'm latching on like a bit bull, right or not.

Ah, this makes more sense. It's one-way roads from the Model's point of view, but occasionally the Controller might yell at the View to save it a trip to the Model.

Communication Within The MVC Triad
...
The Passive Model

In the simplest case, it is not necessary for a model to make any provision whatever for participation in an MVC triad. A simple WYSIWYG text editor is a good example. The central property of such an editor is that you should always see the text as it would appear on paper. So the view clearly must be informed of each change to the text so that it can update its display. Yet the model (which we will assume is an instance of String) need not take responsibility for communicating the changes to the view because these changes occur only by requests from the user. The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model -- or the controller could specify to the view what has changed. In either case, the string model is a completely passive holder of the string data manipulated by the view and the controller. [more mfn emph]

Though note that this only works on a locked resource in the Model, like the text editor hypothetical here. You can't do passive (well) in practice without very stringent locks, which is what the next section in the doc explains -- you need to have the View listening to the Model for changes, and event handling is born. Say someone else (an object other than its own Controller) changes the string that the text editor is editing -- the View needs to be alerted. And complex listening is born.

And since we can nest Views (a window holds multiple text boxes, eg, and both the Window and each text box has a View and a Controller) and since each needs to listen in on [different?] Models and Controllers in case of change (Controller says button for "Create new text doc" is pressed; wipe the View at the Window level and start over), what we've really got is an exceptionally finely channeled encapsulation for UI design that works well within, for instance, a 3-tiered setup. I think the bottom line is that MVC gets complicated quickly with a complicated UI, but to fully flesh it out causes some slick encapsulation and very easy maintenance. Afaict, IANAL, LMNOP.

In other vents, did I mention I hate the new Blogger interface? Hate it. It's so far from WYSIWYG that a 6 year-old could do better. What's wrong with the beautiful simplicity of the current Edit Html tab that I love, and that used to pop up with BlogThis? Seriously, I have to double check my View (har) every time I freakin post from BlogThis now. I HATE THE NEW BLOGGER INTERFACE. HATE HATE HATE HATE HATE. No kidding.

Labels: blogger, code, mvc, noteToSelf

The most annoying thing about setting up a WCF is the number of things that seem to work in the local testing server that'll explode in IIS. The local testing server that you can invoke with F5 is very lenient.

But before we get into the complicated stuff, a quick list of System-Provided Bindings from Microsoft:

WSHttpBinding
A secure and interoperable binding that is suitable for non-duplex service contracts.
BasicHttpBinding
A binding that is suitable for communicating with WS-Basic Profile conformant Web services, for example, ASP.NET Web services (ASMX)-based services. This binding uses HTTP as the transport and text/XML as the default message encoding.
WebHttpBinding
A binding used to configure endpoints for WCF Web services that are exposed through HTTP requests instead of SOAP messages.

Fair warning: I've done this three or four times now to make sure things work, but I haven't started from scratch on a new machine to run through the steps as I present them, here. Could be wonky somewhere. YMMV.

So let's start a WCF Service project. You select File >>> New Web Site >>>WCF Service. Save the new project in IIS's root folder.

That'll create a project with the file structure seen below:

Looking in Web.config, you'll see that, by default, this project has two endpoints. One is the MEX endpoint, which is nice, but not really the business end of things. The other is a wsHttpBinding. That's important, because, as we learned above, that expects to be called from a SOAP-compliant client.

If you try hitting F5 off the bat, it'll seemingly work, first going to a URL like this one:
http://localhost:50319/WCFService1/Service.svc

But if you try to view the GetData method, which is one of the two IService methods that Service.cs implemented by default, using a URL like this one:
http://localhost:50319/WCFService1/Service.svc/GetData

... you get no response, just a 400 error.

So it's worth saying that it's odd to have a SOAP client in my line of programming. You'd usually rather send out a very simple AJAX request to a URL from a web page to the WCF and receive some JSON back to parse in Javascript. The take-home is that we need to remove the wsHttpBinding (set up for SOAP) and set up webHttpBinding (ready for REST) instead.

The endpoints that Visual Studio inserts into web.config by default are below:

<endpoint address="" 
        binding="wsHttpBinding" contract="IService">
        <!-- 
                Upon deployment, the following identity element should be
                removed or replaced to reflect the identity under which the
                deployed service runs.  If removed, WCF will infer an
                appropriate identity automatically.
        -->
        <identity>
                <dns value="localhost"/>
        </identity>
</endpoint>

Our next step is to change that wsHttpBinding endpoint to one with webHttpBinding. I've also inserted the additional overhead of adding a JsonBehavior. Honestly, not sure what that's doing yet, but I think I want it.

<system.serviceModel>
        <!-- serviceHostingEnvironment aspNetCompatibilityEnabled="true" / -->

        <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
        <behaviors>
                <serviceBehaviors>
                        <behavior name="ServiceBehavior">
                                <!-- To avoid disclosing metadata information, set
                                        the value below to false and remove the
                                        metadata endpoint above before deployment
                                -->
                                <serviceMetadata httpGetEnabled="true"/>
                                <!-- To receive exception details in faults for
                                        debugging purposes, set the value below to
                                        true.  Set to false before deployment to avoid
                                        disclosing exception information 
                                -->
                                <serviceDebug includeExceptionDetailInFaults="false"/>
                        </behavior>
                </serviceBehaviors>
                <endpointBehaviors>
                        <behavior name="JsonBehavior">
                                <webHttp />
                        </behavior>
                </endpointBehaviors>
        </behaviors>

        <services>
                <service name="Service" behaviorConfiguration="ServiceBehavior">
                        <endpoint address="" binding="webHttpBinding" 
                                behaviorConfiguration="JsonBehavior" contract="IService">
                                
                                <!-- original:
                                endpoint address="" 
                                binding="wsHttpBinding" contract="IService" -->

                                <!-- 
                                        Upon deployment, the following identity
                                        element should be removed or replaced
                                        to reflect the identity under which the
                                        deployed service runs.  If removed, WCF
                                        will infer an appropriate identity
                                        automatically.
                                -->
                                <identity>
                                        <dns value="localhost" />
                                </identity>
                        </endpoint>
                        <endpoint address="mex" 
                                binding="mexHttpBinding" 
                                contract="IMetadataExchange" />
                </service>
        </services>
</system.serviceModel>

(In case I've screwed up, the entire config is here.)

Again, switching from wsHttpBinding to webHttpBinding makes it so that we can use a URL to access the method. With wsHttpBinding, you'd have to have a SOAP client, which involves insane amounts of overhead for most of my applications.

There's more required than that, however. If you've got the same standard setup as I get in VS 2010, you've got two methods in the Service.cs file. One is pretty easy to set up to listen to query strings for its parameters;

[OperationContract]
[WebGet(RequestFormat = WebMessageFormat.Json, 
        ResponseFormat = WebMessageFormat.Json, 
        BodyStyle = WebMessageBodyStyle.WrappedRequest)]
string GetData(int value);

Now, you should be able to nav to GetData and slap in a param of "?value=1231" and have that number repeat back to you with a URL like this:
http://localhost:50319/WCFService1/Service.svc/GetData?value=10

You'll see "You entered: 10" (with quotes) in the web page.

You can also leave the port off if you followed the instructions and created the dir in IIS' home dir and created the application using Internet Information Server (IIS) Manager. Go to your default web site, find your server's folder, right click, convert to application, and voila:

Unfortunately, the other method in the default project (GetDataUsingDataContract) is more complicated, as if you try to turn it into a GET-able method, your WCF Service will complain about the CompositeType hand-rolled datatype that's also part of the project VS 2010 dreams up for you.

[OperationContract] CompositeType GetDataUsingDataContract(CompositeType composite);
You can't webget that because CompositeType isn't serializable.

Operation 'GetDataUsingDataContract' in contract 'IService' has a query variable named 'composite' of type 'CompositeType', but type 'CompositeType' is not convertible by 'QueryStringConverter'. Variables for UriTemplate query values must have types that can be converted by 'QueryStringConverter'.

Whoops. I'm not going to go into serializing to JSON right now. All things considered, that's an easy afterthought after this XML config wading.

So perhaps not the best composed, but that's today's lesson.

(A decent walkthrough of a slightly different way to go about this here.)

Labels: c#, code, wcf, xml