Adventures on the edge

Source code available on GitHub => https://github.com/BillKrat/Framework

“Dependency Injection has become a first class citizen”, I heard this in a video I was watching on ASP.NET MVC 5 and judging by the latest release it is very impressive indeed;  Microsoft nailed it with ASP.NET MVC

I’ve been using the Microsoft.Practices.Unity container (not to be confused with the Unity gaming framework) since its conception and would like to continue doing so  (versus using the ASP.NET MVC internal IOC container).  So I created a wrapper for Unity’s IUnityContainer instance and expose it from my IGwnContainer Container property (code shown below).   I use lazy instantiation to load my Unity container in the getter which comes registered with a logger, event aggregator, AppSettings, and other features provided by my GwnClassBase.

using Microsoft.Practices.Unity;

namespace Gwn.Library.Common.Entities
{
    public class GwnContainer : IGwnContainer
    {
        private IUnityContainer _container;

        public IUnityContainer Container
        {
            get
            {   // Lazy instantiation so we'll always return
                // the same container
                if (_container == null)
                {
                    _container = new GwnClassBase().GetContainer();
                    _container.RegisterInstance<IGwnContainer>(this);
                }
                return _container;
            }
            set { _container = value; }
        }
    }
}

Figure 1 coding in Startup.cs required to implement Unity Container

On line 72 in figure 1, I added the IGwnContainer interface to the Startup.Configure method parameters which uses ASP.NET MVC parameter injection to provide an instance.  on lines 76-78, I register IFactory and IConcreteProcessor with my Unity Container which are used by my DataController Web API REST service. 

That is all the “coding” my ASP.NET MVC application required to activate the REST Service – I can now do the following from my Web application!  How is this possible?

Figure 2 using a REST Web API service from a ASP.NET MVC application

Well, there is one more step to perform, but it doesn’t require coding, by adding a reference to my Gwn.Library.AspNet project it automagically pulled in the DataController (code shown below) simply because it exists in the library and has a Route(“svc/[controller]”) attribute.  Now any URL for this web application that starts with “svc/data” automatically ends up in this DataController – very cool….

Note: referencing the code below, my Unity container comes into play in the DataController constructor.  I use constructor injection so that the ASP.NET MVC framework will serve up my IGwnContainer instance where I use the Container property to resolve the IFactory instance.  From that point on the _factory field will be used by the data controller to handle request.

using Microsoft.AspNet.Mvc;
using Gwn.Library.Data.Results;
using Gwn.Library.Data.Events;
using Microsoft.Practices.Unity;
using Gwn.Library.Data.Factories;
using Gwn.Library.Common.Entities;

// ----[ !!! THIS FILE IS LINKED !!! ]----------------------------------------
//  FROM: Gwn.Library.AspNet\Controllers\DataController.cs
//    TO: Gwn.Test.Library.Data (Gwn.Library.AspNet folder)\DataController.cs
// ---------------------------------------------------------------------------
// For more information on enabling Web API for empty projects, 
// visit http://go.microsoft.com/fwlink/?LinkID=397860

namespace Gwn.Library.AspNet.Controllers
{
    [Route("svc/[controller]")]
    public class DataController : Controller
    {
        public IUnityContainer Container;
        private IFactory _factory;

        public DataController(IGwnContainer gwnContainer)
        {
            Container = gwnContainer.Container;
            _factory = Container.Resolve<IFactory>();
        }
        [HttpGet("{factoryName}")]
        public ServiceResult Get(string factoryName)
        {
            var args = new ServiceEventArgs(ServiceEventType.Get);

            var factoryArgs = new FactoryEventArgs(factoryName);
            var factory = _factory.GetFactory(this, factoryArgs);
            var processor = factory.GetConcrete();

            var serviceResult = processor.Execute<ServiceResult>(this, args);
            return serviceResult;
        }
        [HttpGet("{factoryName}/{id}")]
        public ServiceResult Get(string factoryName, string id)
        {
            var args = new ServiceEventArgs(ServiceEventType.Get, id);

            var factoryArgs = new FactoryEventArgs(factoryName);
            var factory = _factory.GetFactory(this, factoryArgs);
            var processor = factory.GetConcrete();

            var serviceResult = processor.Execute<ServiceResult>(this, args);
            return serviceResult;
        }
        [HttpPost]
        public ServiceResult Post([FromBody]ServiceParameter para)
        {
            var args = new ServiceEventArgs(ServiceEventType.Post, para.Id);

            var factoryArgs = new FactoryEventArgs(para.Factory);
            var factory = _factory.GetFactory(this, factoryArgs);
            var processor = factory.GetConcrete();

            var serviceResult = processor.Execute<ServiceResult>(this, args);
            return serviceResult;
        }

        [HttpPut("{id}")]
        public ServiceResult Put(string id, [FromBody]ServiceParameter para)
        {
            var args = new ServiceEventArgs(ServiceEventType.Put, id);

            var factoryArgs = new FactoryEventArgs(para.Factory);
            var factory = _factory.GetFactory(this, factoryArgs);
            var processor = factory.GetConcrete();

            var serviceResult = processor.Execute<ServiceResult>(this, args);
            return serviceResult;

        }

        [HttpDelete("{factoryName}/{id}")]
        public ServiceResult Delete(string factoryName, string id)
        {
            var args = new ServiceEventArgs(ServiceEventType.Delete, id);

            var factoryArgs = new FactoryEventArgs(factoryName);
            var factory = _factory.GetFactory(this, factoryArgs);
            var processor = factory.GetConcrete();

            var serviceResult = processor.Execute<ServiceResult>(this, args);
            return serviceResult;
        }
    }
}

Obviously I don’t want this Gwn.Library.AspNet project to become bloated with every applications data requirements, so I created a generic DataController that handles the REST operations GET, POST, PUT, and DELETE.  This nicely covers my data CRUDL requirements (create, read, update, delete, and list) .  

It is the IFactory implementation, which will be configured by the application, that will handle what implementation to use for the application’s data requirements.   I’ll show code below that demonstrates how this generic DataController can allow the application to use its own implementation.

The default Factory implementation will handle most requirements; it will permit most Factory classes to look as simple as the following:

namespace Gwn.Library.Data.Factories
{
    /// <summary>
    /// Test factory uses the default configuration which
    /// depends on the following interfaces to be registered:
    /// <see cref="IFactory"/>, 
    /// <see cref="IConcreteProcessor"/>
    /// </summary>
    /// <example><code><![CDATA[
    /// 
    ///    _container = new GwnClassBase().GetContainer();
    ///    _container
    ///        .RegisterType<IFactory, TestFactory>()
    ///        .RegisterType<IConcreteProcessor, TestProcessor>()
    ///        ;
    /// 
    /// ]]></code></example>
    public class TestFactory : FactoryBase
    {
    }
}

public class TestFactory : FactoryBase
{
    public override IFactory GetFactory(object sender, EventArgs e)
    {
        // Use Unity named registrations for factory pattern.
        // These registrations could be made here - but are
        // better done in the application
        Container
            // http://MyApp/svc/data/UserData/MyID
            .RegisterType<IFactory, UserFactory>("UserData") 

            // http://MyApp/svc/Data/TestData/MyID
            .RegisterType<IFactory, TestFactory>("TestData") 
            ;

        var args = e as FactoryEventArgs;
        return Container.Resolve<IFactory>(args.FactoryName);
    }
}

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.Practices.Unity;
using Gwn.Library.Common.Entities;
using Gwn.Library.Data.Factories;
using Gwn.Library.Data.Processors;
using Gwn.Library.AspNet.Controllers;
using Gwn.Library.Data.Events;
using System;
using Gwn.Library.Data.Results;

namespace Gwn.Test.Library.Data.Fixtures
{
    [TestClass]
    public class DataControllerFixture
    {
        private const string clientFactoryParameter = "Test";

        private IUnityContainer _container;
        private DataController _controller;

        [TestInitialize]
        public void InitializeTest()
        {
            _container = new GwnContainer().Container;

            // Register the TestFactory and TestProcessor for use
            // by the DataController (in Gwn.Library.AspNet)
            _container
                .RegisterType<IFactory, TestFactory>()
                //                                ▼▼▼▼▼▼▼▼▼▼▼▼▼
                .RegisterType<IConcreteProcessor, TestProcessor>();
            //                                    ▲▲▲▲▲▲▲▲▲▲▲▲▲
            _controller = _container.Resolve<DataController>();

            Assert.IsNotNull(_controller, "Controller null, all test will fail");
        }


        //           ▼▼▼▼▼▼▼▼▼▼▼▼▼
        public class TestProcessor : ProcessorBase
        //           ▲▲▲▲▲▲▲▲▲▲▲▲▲
        {
            public override T Execute<T>(object sender, EventArgs e)
            {
                var args = this.EventArgs as FactoryEventArgs;
                var returnResult = new ServiceResult();

                Func<string> parameter = () =>
                    args.ServiceParameter == null ? "NA" : (args.ServiceParameter.Id ?? "NA");

                var data = $"ID: [{args.Id ?? "NA"} / {parameter()}] TYPE:{args.ServiceEventType}";

                returnResult.Data = data;
                returnResult.FriendlyMessage = args.ServiceParameter?.Message ?? "Friendly Message";
                returnResult.DeveloperMessage =
                    $"Factory=[{args.FactoryName}] [{args.ServiceParameter?.Tag ?? "NA"}]";

                return (T)(object)returnResult;
            }
        }


        [TestMethod] // template: svc/data/Test
        public void Can_GET_FromDataController()
        {
            var result = _controller.Get(clientFactoryParameter);

            var expected = "ID: [NA / NA] TYPE:Get";

            Assert.AreEqual(expected, result.Data);
            Assert.AreEqual("Friendly Message", result.FriendlyMessage);
            Assert.AreEqual("Factory=[Test] [NA]", result.DeveloperMessage);
        }

        [TestMethod] // template: svc/data/Test/100
        public void Can_GET_WithID_FromDataController()
        {
            var para = "100";

            var result = _controller.Get(clientFactoryParameter, para);

            var expected = "ID: [100 / NA] TYPE:Get";

            Assert.AreEqual(expected, result.Data);
            Assert.AreEqual("Friendly Message", result.FriendlyMessage);
            Assert.AreEqual("Factory=[Test] [NA]", result.DeveloperMessage);
        }

        [TestMethod] // template: svc/data     [FromBody]ServiceParameter para
        public void Can_POST_ToDataController()
        {
            var serviceParameter = new ServiceParameter
            {
                Id = "500",
                Factory = "Test-Factory"
            };

            var result = _controller.Post(serviceParameter);

            var expected = "ID: [NA / 500] TYPE:Post";

            Assert.AreEqual(expected, result.Data);
            Assert.AreEqual("Friendly Message", result.FriendlyMessage);
            Assert.AreEqual("Factory=[Test-Factory] [NA]", result.DeveloperMessage);
        }

        [TestMethod] // template: svc/data/250    [FromBody]ServiceParameter para
        public void Can_PUT_ToDataController()
        {
            var serviceParameter = new ServiceParameter
            {
                Id = "500",
                Factory = "Test-Factory",
                Message = "Replace Friendly Message",
                Tag = "Can be used for anything" 
            };

            var result = _controller.Put("250", serviceParameter);

            var expected = "ID: [250 / 500] TYPE:Put";

            Assert.AreEqual(expected, result.Data);
            Assert.AreEqual("Replace Friendly Message", result.FriendlyMessage);
            Assert.AreEqual("Factory=[Test-Factory] [Can be used for anything]", result.DeveloperMessage);
        }
    }
}

public class ServiceParameter : ParameterBase
{
    #region The Id and Factory Properties are used by framework

    public string Id { get; set; }

    public string Factory { get; set; }

    #endregion


    // The following are used by the implementation as applicable

    public string Tag { get; set; }

    public string Message { get; set; }

}

This adventure cost me a few hours of my life…

This occurred when I tried to programmatically get a string from the resource loader.

If I called the resource file Resources.resw and placed it in my Strings\en-us path of my application then it sorta-kinda works. 

It sort-kinda works because where you can get simple content, e.g., “TestString” as shown on line 49 in the line below (infoR variable in red box of bottom pane), you can’t programmatically retrieve the control resources such as EmailTextBlock.Text and LostPasswordButton.Content.  Localization did however work using the XAML UID – just not programmatically.

I have a work-around for that as well but first let’s address the error that started all of this.

The problem was that I had a Gwn.Library.Desktop project that has its own resource file and I needed to reference the resources from a view within this very same library.  Long story short, I could not get localization to work at all (programmatically or through binding) unless the Application had a copy of the resource file.  

To resolve this issue I opted to have a “linked” copy of the resource file from my Gwn.Library.Desktop project in the Application – this way I only have to update one file.  

1. I named my resource file DesktopResources.resw
2. Right click on this file and copied the path to clipboard
3. Navigated to my Application Strings\en-use path and then right clicked on it
4. Added existing item and pasted the path into the File name box.
5. Selected the dropdown (right down triangle) and selected “Add as Link”

With this change done I now had localization that worked with XAML UID (as expected) as well as the ability to programmatically retrieve strings using a my GetLocalizedText<T>() method.  Note that in this method (line 34 of image below) that I have to specify the name of my resource file in the ResourceLoader constructor.

Likewise I had to ensure that my UID settings were prefixed with the resource filename (not required if you use the default name of resources.resw). 

OCT-25-2016 Thank you Matt Cecile for providing the following great tip:
   You say " I cannot retrieve resources that have a property attached". Its simple actually:
          var resourceLoader = new ResourceLoader("DesktopResources");
          var value = resourceLoader.GetString(resourceName + "/Text");
    or /Content, or whatever property you are trying to get.

With the environment setup now, and localization working within XAML, I now have to work-around the issue presented above where I cannot retrieve resources that have a property attached.  To do this I programmatically build a XAML control using the provided type, load it, and then cast the resulting instance as required to get the Text or Content value using the extension method below:

/// <summary>
/// Class StringExtension.
/// </summary>
public static class StringExtension
{
  /// <summary>
  /// Gets the localized text.
  /// </summary>
  /// <typeparam name="T"></typeparam>
  /// <param name="resourceName">Name of the resource.</param>
  /// <returns>System.String.</returns>
  public static string GetLocalizedText<T>(this string resourceName)
  {
     var resourceLoader = new ResourceLoader("DesktopResources");
     var value = resourceLoader.GetString(resourceName);

     if (string.IsNullOrEmpty(value))
     {
        var ctrlType = typeof(T).Name;

        var xaml = 
          $"<Grid xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation'>" +
          $"<{ctrlType} xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml'  " +
          $"x:Uid='{resourceName}'  x:Name='Content' />" +
          $"</Grid>";

        var control = XamlReader.Load(xaml) as Grid;
        var result = control?.FindName("Content");
        if (result == null) return "";

          switch (ctrlType)
          {
             case "TextBlock": return ((TextBlock)result).Text;
             case "Button": return ((Button)result).Content?.ToString();
             default:
                 return "";
          }
      }
      return value;
   }
 }

“Those who do not remember their past are condemned to repeat their mistakes.”
     - George Santayana

If we hope to grasp the foundation of architectural patterns we have to understand MVC.   Every pattern today hinges on this understanding since they, for the most part, have evolved from it.  MVC knowledge is an important part of becoming an architect as it teaches us the lessons learned from our past great architects, the issues they encountered, and why they evolved to the next pattern as a solution to those issues.

It is also important to know that for ASP.NET MVC, the (C)ontroller in MVC is an overloaded term and has nothing to do with traditional MVC as outlined in this article; the controller in ASP.NET MVC actually behaves more like a Presenter from the Model View Presenter (MVP) pattern.

Figure 1 – Learn from our past architects, lest history repeats itself…

Martin Fowler tells us in his GUI Architecture article ⁶ that MVC is the most misquoted pattern, and this was among those architects that understood the Smalltalk environment.   To complicate matters, we (todays developers) lack a common core of experience with our great architects (and their articles), e.g., we don’t know what a “controller” is because we’ve never had to work with one, so it is understandable how MVC can be hard to grasp.  

Understanding the Controller

“Another irritating feature of MVC, at least with respect to Dolphin, was that the idea of a controller did not fit neatly into the Windows environment. Microsoft Windows, like most modern graphical operating systems, provides a set of native widgets from which user interfaces can be constructed. These "windows" already include most of the controller functionality embodied as  part of the underlying operating system control.” ⁷

The above statement eludes to the underlying difficulty in our ability to understand MVC;  it was not designed for Windows (or modern) operating systems – it was designed for systems that had to monitor user inputs and process them manually. Unlike Windows, those systems did not have controls (supported by an operating system) that did all the work for them, they had to manually manage framework features that we take for granted.

For those systems, if you created a text control (view) you had to create a way to communicate with it (update the display from data) as well as a way for the control to communicate with the application (update data from input) – this is where the MVC controller came in.  There were a collection of controllers, one for each control on the screen (controller-view pair).  Only one controller could have control at anytime (the one receiving the input) so a ControlManager was responsible for managing the hierarchical of controllers to ensure the proper controller was active ³.

The system had input sensors (keyboard or mouse) and as the user interacted with the controls (gestures), the active controller would broadcast the applicable message.

Figure 2: Model-View-Controller State and Message Sending ²

When the controller was initialized it was linked to both a model and a view (control), likewise the view is linked to the model.  When a user selects a control (via keyboard or mouse) the controller associated with that control is made active and it broadcast the user input as a message.  

This message contains a symbol (#propertyName) and the applicable value ⁶.   The model receives this message and updates the applicable property on it.  It then notifies the view that there was a property changed so that it can refresh its associated view, or views (if more than one control are linked to the model property).  

So when you understand the role of the view-controller pair as follows:  “The view and controller are supposed to create and maintain the user interface, track user events, and update the model when appropriate” ⁴. You’ll better understand that it is the model that handles all of the application business logic – not the controller or its view.   

In summary, at the highest level the controllers only responsibility is to get the user inputs to the model.  If we look at todays controls, i.e., a text control, we do not have to worry about this.  We can either take a passive approach and grab the content from the textbox control and place it on the model, or we can use data-binding so that as the content is changed the model is automagically updated – the controller functionality is done for us under the hood of the control.

Armed with this information, you can see that with the Windows operating system there is no “C” in MVC – only MV.  Some architects wrongly believe the the “C” in MVC is analogous to the “P” in MVP, because they believe the controller is where all of the business logic resides.   If they understood MVC they would know that the “P” in MVP is actually analogous to the  “M” in MVC because in MVC the model contains all of the business logic, later it was moved to a Presentation/Application, aka view model (more on this below) – this is explained further in the article referenced below “Twisting the Triad”.

Model View Pattern

With Windows the pattern now becomes MV because there is no controller.  This does not mean that the MVC pattern conceptually does not apply to us – it still does.  For all practical purposes there is no functional difference because the view-controller pair of MVC and the view of today’s control.  When it comes to the principles (and issues) of MVC they apply equally to both of us because our view functioned the same function as their controller-view. 

Figure 3: Windows View-Model pattern (there is no controller)

Understanding the Model

“This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface.” ⁷

Definitions

Domain Object (aka Entity)
A domain object is a class that has a clear separation of concerns; it represents a single entity.  For example a User domain object would have Last, First, MI, Address, and Email properties.  it “should be completely self contained and work without reference to presentation, they should also be able to support multiple presentations” ⁶. 

What does “work without reference to presentation” mean?  If the view has a behavior where the email content displays in red if it is invalid, you would have a EmailTextColor property on your model to trigger this behavior – since this is presentation state, you would not want the EmailTextColor property in your domain object; to be technically correct you would place this in the evolved MVC Application Model (discussed below).

Model

A model, by today’s definition, is a class.  This class will have properties and methods to handle the business rules of the application; in MVC all processing is done by the Model.  The model properties could be any type, i.e., bool, string, etc. as well as entities such as the User entity discussed above.

In MVC, the user inputs are sent to the model via a controller message.   The model updates the applicable property and then notifies the view that there was an update.  The view is responsible for refreshing itself with the applicable data from the model.

In MV, the user inputs into a control and it automatically updates the model if using the Observer pattern (data binding).  If Passive view is being used (no data binding) then the view’s code-behind would have to manually update the model.

In either case, MVC or MV, the model is changed and/or notified of a request (button click) and the model is responsible for processing the applicable business logic.   Neither the view nor controller (in the case of MVC) handles business logic – only the model does.

Application Model / Presentation Model (aka MVVM)

Note: the Presentation Model is similar to the Application Model with the exception that the Presentation Model does not permit you to update the view ^6. 

”Smalltalk 80's MVC was very influential and had some excellent features, but also some faults. As Smalltalk developed in the 80's and 90's this led to some significant variations on the classic MVC model.” ⁶.  One of these changes was the use of an “Application Model” (discussed below) which sits between the view and the model, this allowed for the purity of domain objects by moving presentation state to this new Application Model.   Note: the Application Model can consist of your domain objects, but is typically specialized to handle UI behavior ⁵.

All of the business logic was moved out of the domain into the Application Model, which in today’s terms is referred to as a “view model”.  A noted limitation of MVC was the complexity of code required to update the view from the model (particularly since it had no reference to the view), complex view behaviors required special coding and property objects; this was often seen as too much work so unlike the Presentation Model, the Application Model was allowed to modify the UI directly ⁶.

Figure 4: Functional model (view-controller pair represented only as view above to be consistent with Windows OS)

Understanding the View

“The View displays the Model on the screen. View provides a simple protocol to pass information to and from the Model. The heart of a View object presents the Model data in one particular way that is of interest to the end user. Different views may support the same data, i.e., the same Models, in completely different ways. The classic example is that one View may show data as a bar graph while another shows the same data as a pie chart.” ¹ 

“Each view may be thought of as being closely associated with a controller, each having exactly one model, but a model may have many view/controller pairs”. ²

With the Application and Presentation Model,  the view only communicates with the view model - not the domain model; this permits the domain objects to maintain their purity in terms of not having any presentation state or contain “application” business logic in them. 

Lessons Learned

The evolution to the Model View Presenter (MVP) pattern was the solution to the problems inherent in the evolved MVC patterns as noted by Andy and Blair in their “Twisting the Triad” article, Mahemoff and Johnston in their “Handling Multiple Domain Objects with MVC”, and the issues I experienced myself.

My experience working on large projects based on MVVM seemed consistent; I have found that the Presentation Model (MVVM) lends itself to code bloat and the inability to reuse components.  As such, I have had to refactor frameworks to MVP-VM to overcome the shortcomings which evolved into blocking issues.  some of the pain points that I have encountered follow (perhaps you recognize them as well?):

• All of the business logic is placed in the Application Model (view model) which will have dependencies on domain objects that are more application centric than what a particular view requires.  If another view wants to reuse a view model it has to pull in its domain objects and business logic as well, e.g., if it wants to reuse the drain it has to pull in the kitchen sink, which has to pull in the kitchen, which pulls in the house, which pulls in the yard… the architect might find it easier to add on another kitchen, with its own sink, to have the drain that can be reused for their purpose… 
• A big issue I’ve seen is when the view model (for all practical purposes) becomes a view code-behind file; the view is so tightly coupled to the view model, the view model serves no other purpose than to handle that one view.  The sad part is the view doesn’t even have the benefit of being able to access the view – which lends itself to the next issue.
• Another big issue is when the view’s code-behind ends up being utilized for business logic because it is inaccessible from the view model. What’s worse is when views contains child views that have their own code-behind files.  It becomes difficult to locate  where the actual business logic resides, particularly with data-binding in the mix - in many cases it can be almost impossible to locate business logic without the assistance of an application such as Snoop because of a deep hierarchical nesting of view/view models with code in both.
• The biggest issue - without the ability to reuse components the application becomes monolithic, hard to maintain, and is not easily extensible.
  

Below is an excerpt from “Twisting the Triad” – it eludes to the frustration in working with the evolved MVC pattern:

“By now we were once more becoming somewhat disheartened with our framework approach. We were left holding two possibilities that, although adequate, were flawed in several respects (and, when one is engaged on a quest to create the perfect development environment, such flaws seem all the more debilitating).

So, where were we? We liked the Observer aspect of MVC and the flexibility that came from its pluggable nature but it just didn't seem correct that the link between the application model and view was an indirect one. Also, the requirement for "controllers" in the Windows environment seemed out-moded.

To be honest, we didn't feel confident about tinkering with these aspects of MVC purely as the result of our own intuition; we’d wasted enough time already. We were on the point of giving up and resigning ourselves to using our existing interpretation of MVC when a colleague asked if we had looked at Taligent's Model View Presenter framework?” ⁷

REFERENCE: Mahemoff, Johnston - Handling Multiple Domain Objects with MVC ⁴

Note: for brevity I only mention the titles – please read the article from reference links below.

Problem 2: Each model-view-controller package should rely on as few other packages as possible

Problem 3: How can views and controllers present information relating to one model and simultaneously enable a user to change another model?

Problem 4: Some models and views have their state defined by one or more models.

Problem 5: Some models reference other models and need to know that they have changed.

REFERENCE: Andy Bower, Blair McGlashan - Twisting the Triad ⁷

“In MVC, it is a view's responsibility to display the data held by a model object. A controller can be used to determine how low-level user gestures are translated into actions on the model. The various components, M, V and C are all pluggable for maximum flexibility. Generally, a view and controller are directly linked together (usually by an instance variable pointing from one to the other) but a view/controller pair is only indirectly linked to the model. By “indirect”, I mean that an Observer relationship1 is set up so that the view/controller pair knows about the existence of the model but not vice versa. The advantage of this comes because it is then possible to connect multiple views/controller pairs to the same model so that several user interfaces can share the same data. Unfortunately, it is the nature of this indirect link that causes the problems with MVC.”

“In MVC, most of the application functionality must be built into a model class known as an
Application Model2 (see figure 1). It is the responsibility of the application model to be the mediator between the true domain objects and the views and their controllers. The views, of course, are responsible for displaying the domain data while the controllers handle the raw user gestures that will eventually perform actions on this data. So the application model typically has methods to perform menu command actions, push buttons actions and general validation on the data that it manages. Nearly all of the application logic will reside in the application model classes. However, because the application model’s role is that of a go-between, it is at times necessary for it to gain access to the user interface directly but, because of the Observer relationship between it and the view/controller, this sort of access is discouraged”.

“let's say one wants to explicitly change the colour of one or more views dependent on some conditions in the application model. The correct way to do this in MVC would be to trigger some sort of event, passing the colour along with it. Behaviour would then have to be coded in the view to "hang off" this event and to apply the colour change whenever the event was triggered. This is a rather circuitous route to achieving this simple functionality3 and typically it would be avoided by taking a shortcut and using #componentAt: to look up a particular named view from the application model and to apply the colour change to the view directly. However, any direct access of a view like this breaks the MVC dictum that the model should know nothing about the views to which it is connected. If nothing else, this sort of activity surely breaks the possibility of allowing multiple views onto a model, which must be the reason behind using the Observer pattern in MVC in the first place.“

References

1. Trygve Reenskaug and James Coplien - March 20, 2009.  The DCI Architecture: A New Vision of Object-Oriented Programming 
2. Krasner, Glenn E.; Pope, Stephen T. (Aug–Sep 1988). "A cookbook for using the model–view controller user interface paradigm in Smalltalk-80". Also published as "A Description of the Model–View–Controller User Interface Paradigm in the Smalltalk-80 System" (Report).
3. Burbeck, Steve (1992) Applications Programming in Smalltalk-80:How to use Model–View–Controller (MVC)
4. Mahemoff, Johnston.  Handling Multiple Domain Objects with Model-View-Controller. 
5. Hopkins, Horan. SmallTalk an introduction to application development using VisualWorks
6. Martin Fowler (2006), GUI Architectures.
7. Andy Bower, Blair McGlashan. Twisting the Triad, The evolution of the Dolphin Smalltalk MVP application framework

It is recommended that you familiarize yourself with Working with Multiple Environments, it is a comprehensive article that goes into detail on how to configure your application for Development, Staging, and Production.  

One of the first things I encountered was that the launchSettings.json file was not available under Properties (reference bottom pane of figure 1).   A second issue I encountered was that the StartupDevelopment and StartupStaging class methods were not not being invoked as expected – the application defaulted to the Startup class methods.

Figure 1

To resolve the first issue I switched over to the “web” profile (discussed in the article) and set the ASPNET_ENV value to Staging.   There was an asterisk indicating that the project’s Debug setting was changed.  Once I clicked the save button (see #3 top of figure 2) the launchSettings.json file was created (ref figure 3).

Figure 2

Figure 3

The second issue required me to step through the source code.  Where the Startup conventions worked for methods, e.g., ConfigureDevelopment() was invoked, I could not get my StartupDevelopment class to be recognized by application – it kept defaulting to the Startup class.

In reviewing the source code, line 61 of figure 4 is looking for the startup assembly name (in this case GwnBible) and then StartupDevelopment as set on line 55.  I had created my StartupDevelopment and StartupStaging classes under an Environment folder which was part of the namespace (line 6 of middle pane) – this prevented the classes from being discovered by the StartupLoader.  Once I changed the namespace to GwnBible everything started working as expected.

Figure 4

The actual complete LinqPad error follows:

“Cannot access a non-static member of outer type 'System.Data.Entity.DbContext' via nested type 'UserQuery.SqlStorageDal'”

This occurs when you attempt to access the data context tables or commands (such as SaveChanges) from within classes; it only appears to work within the Main() context of LinqPad.  Since I am using LinqPad to design the data access layer for my Entity Framework data context this was going to be quite restrictive – I’d like to complete the basic work here and transfer the classes into my final project without refactoring.

My workaround was to create some private fields (reference bottom right pane in image below) and then provide it instances from within the Main() method.  I can then access these private fields from my class code (top right pane in image below).   When I migrate this code into my live projects I can copy/paste these private fields into my class and set references from my constructor or initialization code.