The Modified MVC Design Pattern

This MVC Showcase Design Pattern is the Modern Developer’s variation of the Model/View/Controller Design Pattern that is built using the Microsoft MVC Framework.

This Design Pattern Variation is NOT the Microsoft’s Architecture Model

The design and its processes are combinations of real world successes and failures to produce a Best Practice MVC Application Model.

This Version of the MVC Design Pattern an Architecture Model that has been Vetted in Real-time

… The Design has performed as a Successful Architecture in Real World Enterprise Environments

This MVC Showcase Design Pattern adds the “View Model” and the “Data Services” design blocks to the original MVC design pattern.

The View Model has been assigned the Behavior Business Logic Responsibility while the Model holds State responsibilities, as DTOs, exclusively.

This Design Pattern Variation uses Naming Conventions and Terminology that has Different Interpretations on the Web

If Initialization is Required it is Performed in a Parameterless Default Class Constructor

If validation or initialization logic is required it can be implemented as Private Access Modifier calls. This is the only exception for Behavior Actions in a State DTO Model.

The View Request DTO will be Derived from a Common Request DTO that holds Application Common Properties

These Base Class Data Properties can contain Client-side Session Information that is common to all View Requests such as Session Request Logging Information.

If Client-side validation is required MVC Attribute Declarations are used for the Properties requiring validation.

Attribute Declarations on Model Properties within the View Response DTO is one of the Primary Justifications for this DTO.

… By Delivering a Tailor-made DTO to the View and not just Delivering a Raw Information Services Return DTO

…… We have Opened Up Possibilities not Available in a DTO that could Span Multiple Implementations

This Model class is a state Data Transfer Object (DTO). The Model is a Plain Old CLR or C# objects (POCO) class

The Model is Constructed with a View Model Factory Method Call to its Model Factory Helper…

… All DTO Transformations and Business Rules logic is Performed in the Model Factory Helpers

The final Model, with its Error Handling objects, is returned to the View Model Factory for delivery to the requesting Controller.

The JavaScript frameworks, jQuery and KnockOut, performs Client-side processing and interacts with the Controller using asynchronous AJAX calls.

The Cascading Style Sheets (CSS) are managed using the CSS Transform framework: SASS.

The Controller brokers the View Request to a Business Logic Layer Method call that generates the Model. The Controller then delivers the Model to the View for consumption.

The Controller requests a State Model, to bind to the View, with a call to the View Model Factory.

The View Model Factory processes the View Request DTO received from the Controller.

The View Model Factory returns, to the Controller, a View Response DTO,

This View Response DTO includes the Error Handling information and all the data that the Controller’s Razor View will need to process on the Client Browser request using JavaScript, jQuery, KnockOut and CSS.

A Data Services design block is the lowest level of abstraction.

It controls the flow of the View Response DTO information, requested by the Controller, using the View Request DTO.

This call is made by the View Model Factory

The View Response DTO is the State Object that holds the Data for the View as a Strongly Typed C# POCO Object

This View Response DTO can hold data populated from one of these four Information sources:

1. An external Data Service source delivered through a Web Service Business Layer call
2. An external Data Service source delivered through a Local Library (DLL) Business Layer call
3. The Data Services Caching Service
4. The Data Service Stub Data source for “Fake Data” used for Testing and Development prior the External Data sources being available

The View Response DTO data and error information is passed to its Model Factory Helper as the return object from the call to Data Services by the View Model Factory.

An Off Domain Service is a service that must be called as a Web Service as the source Code Library is not accessible to the Application.
If the Information Services Layer is “Off Domain”, and the Information request in not in the Services Data Cache, then information from a Web Service Business Layer call must be made.

The return from this call is the Information Services Return DTO. This is not the View Response DTO.

The Information Services Return DTO is the Complex DTO package that contains all of the information that a View Response DTO may need, but not necessarily being using in this call.

It holds the Error Handling Aggregate DTO and all supporting Information Composite and Aggregate DTOs.

The Information Services Return DTO is the Source Information for the View Response DTO Transforms

… It is placed in the Services Data Cache if it is the first call for this Information to the Information Services Layer

An On Domain Service is a service can be called from the Source Code Library and is accessible to the Application.

If the Information Services Layer is “On Domain” or local to the Application, then a library call the Business layer is made.

This call is an exact functional representation of the Web Service Business Layer as a Dynamic Link Library (DLL).

This Model allows for a Two-tier Architecture

… an N-tier Architecture

…… or Both Architecture at the Same Time!

The Cache Model can use an In-Memory, ASP.NET Cache or an App Fabric Server Architecture

… This model uses an implementation of the open source “Glav Cache Adapter”

The In-Memory model is the default configuration.

Stub Data Services Return DTO information is an Application level data source created at the beginning of the development process that enables Test Driven Development (TDD) Unit Testing of this lowest level abstraction of the modified MVC design pattern.

The Stub Data option allows for the Three Developer MVC Implantation Process.

1. An Information Services Layer Developer,
2. A View UI Designer
3. An MVC Core Developer

All three developers work together at the beginning of the Sprint Iteration to create the Stub Data Services Return DTO as a fake, or Stub, Information Services Return DTO.

This will let the Information Services Layer Developer and the View Designer understand their requirements along with the MVC Core Developer.

When the Stub Data Services Return DTO is defined and tested

… Then the three developers have all the information they need to complete their respected deliverable tasks