MVC# Overview

Abstract: This article gives an overview of MVC# - a Model-View-Presenter framework for .NET platform. It firstly explains the MVP pattern essentials and then walks through the key features of the MVC# framework which help building true MVP-based solutions.

What is Model-View-Presenter?
    3-tier architecture
    MVC and MVP patterns
Why using MVC#?
    1. Views and controllers get connected automatically
    2. Multiple GUI platforms supported
    3. Platform-independent navigation to views
    4. Tasks concept
Conclusion

What is Model-View-Presenter?

3-tier architecture

One of the most fundamental approaches in software engineering is the Layered architecture. It implies dividing a system into several interacting layers with certain limitations imposed on how layers may interact.s Layered architecture finds its application in various systems for example net protocols (TCP/IP layers), operating systems (three layers: core, drivers, applications) and others.

A particular case of layered architecture is the 3-tier architecture with its variations: Model-View-Controller and Model-View-Presenter. Before considering MVP (and MVC) let us discuss the general 3-tier architecture and its difference to the conventional programming style.

A straightforward (and widely used) approach in designing applications is the 2-tier architecture. According to it an application consists of a presentation layer and a domain layer. Domain layer classes represent the problem domain entities (e.g. customer, order) and are usually bound to some database access facilities. Presentation classes in 2-tier architecture have the following responsibilities:

• receive user input
• make necessary calls to the domain tier
• decide what to show next to the user
• display output

These responsibilities are rather vast and, as a system grows, may result in a bloated presentation layer. Moreover they logically can be divided into two groups: actually presentation logic (code for perceiving input and displaying output) and application logic (communication with the domain tier and application flow decisions). These responsibilities require different programming skills and should better be not mixed in a single module/class. A quite natural solution is to split this too broad presentation layer into two: presentation and application logic:

3-tier architecture is rather abstract. While it declares an existence of three layers, it says nothing about classes in these layers and their interaction. A much more precise form have two 3-tier architecture variations: Model-View-Controller and Model-View-Presenter. Let us proceed to their discussion.

MVC and MVP patterns

According to both MVC and MVP the presentation layer consists of view objects, and application logic consists of controller objects (we will use "controller" name instead of "presenter" in MVP). For each view object a corresponding controller exists and vice versa. And although MVC and MVP are based on a common 3-tier principle: views process only presentation needs and controllers handle application logic, these patterns have two major differences:

1. In MVC controllers receive and process user input, but in MVP views receive user input and then merely delegate processing to the corresponding controllers. That is why MVP pattern better fits modern UI environments (Windows/Web forms) where view classes themselves handle user gestures.
2. In MVC controllers affect their views by changing the intermediate presentation model, which the views are subscribed to (by observer pattern). This makes views pure observers without direct access to them. MVP on the other hand violates this "pure observer" rule by providing a direct link from a controller to its view. This makes MVP more handy as compared to MVC.

The said differences make the MVP pattern more attractive than MVC from the developer's point of view. And indeed MVP was designed to be an evolution of MVC and to improve the latter. That is why we often refer to MVP as "sharp MVC" and therefore the name our MVP framework is MVC#.

Why using MVC#?

Now that we are convinced in the usefulness of the MVP pattern we may start using it in our applications. However it may be not as easy. Maintaining an additional application logic layer may require considerable efforts. For example a developer needs to take care of linking between all views and appropriate controllers,

Fortunately MVC# automates and takes on itself much of the work concerned with MVP usage. Thus it simplifies and speeds up the development of MVP applications. Below is the list of MVC# framework features:

1. Views and controllers get connected automatically

Developers do not have to care about associating views with their controllers. MVC# framework automatically establishes links between views and corresponding controllers:

public class OrderDetailsView
    ...
    private void processOrderButton_Click(object sender, EventArgs e)
    {
        // No code needed to establish a link to the controller
        (Controller as OrderDetailsController).ProcessOrder();
    }

2. Multiple GUI platforms supported

MVC# allows targeting different GUI platforms (Windows, Web, Silverlight, etc.) Thus the same application can be used with quite different presentation layers - one for Windows, the other for Silverlight or Web environment, etc.:

3. Platform-independent navigation to views

To make application logic fully independent of the presentation layer, MVC# provides a platform-independent way of navigating to views. Instead of  activating a Windows form or redirecting to a Web page a developer should simply call a uniform Navigator.Navigate(...) method:

public class OrderDetailsController
    ...
    public void ProcessOrder()
    {
        // No Response.Redirect(...) or Form.Show() calls
        Task.Navigator.Navigate(OrderSupportTask.ProcessOrder);
    }

4. Tasks concept

Another useful feature of MVC# framework, although not directly related to the MVP pattern, is the Task concept. A task unites several views with their controllers in fulfilling some job. For example a ticket booking task may consist of two views: one to choose a ticket, the other - to do the payment. In MVC# all controllers within a task are given a link to the task object. Generally a task can be expressed as a workflow or a state machine.

 

Conclusion

MVC# framework frees developers from much of extra work required in construction of Model-View-Presenter applications. It allows creating flexible MVP-based application with almost no extra cost.

What is MVC Architecture? (Model – View – Controller)

MVC Architecture has implemented by Trygve Reenskaug at 1979 for the first time. It was implemented on Smalltalk at Xerox labs. Then benefits and advantages of this architecture has been accepted by most of the coders and software engineers.

It was an information about MVC’s history above. Now lets talk about what really MVC is. What do you understand from MVC. The word M stands for Model, V stands for View and C stands for Controller. I am going to mention about each item.

The figure above may help you while thinking what structure it might have. Let’s start with Model.

Model:It handles data processing and database works part. Model processes events sent by controller. After processing these events then it sends processed data to controller (thus, controller may reprocess it) or directly to view side.

View:View prepares an interface to show to the user. Controller or model tells view what to show to the user. Also view handles requests from user and informs controller.

Controller:Let’s say controller is like brain of the system. That is right. Because it processes every request, prepares other parts of the system like model and view. Then the system determines what to do by controller’s commands.

Even if you are junior developer you probably faced with a problem called “Complexity of Project”. There MVC comes. MVC helps you to decrease complexity of project. For instance, there is a team with 5 people. If they are working on same project after sometime project reaches a point which no one cannot understand what is project going to be. What i mean is MVC splits project to (by default) three different parts. Like Model, View, Controller.You can say;

As you see above if you split your project three part like Application Development, Database and Data processing and Interface development then of course you project will be more understandable and developers can work more efficiently.

What are the advantages of MVC?MVC is perfect for team work. As i mention before this architecture splits your project into some parts so, team members can work and their parts without any dependency. Then you will realize that MVC makes your project more systematic.
It is really easy to edit or change some part of your project that makes less development cost and maintenance cost.
MVC doesn’t repeats itself. If you wrote some script for your project. Because of non-dependancy property of MVC then you may use this script for another project of yours. And of course it helps you to finish your project by spending less time then others.
And developers doesn’t fight after 5pm 

Why MVC is non-standard?
Still waits for developers to discover itself.  I know some developers who think that they have to write even every semicolon, letter. you don’t have to do that. However, MVC tries to help you to don’t repeat yourself.

Why MVC is too important for Companies?
Well it is not!. Yes that is true. A company only looks for if a project is done on time or not. Most of the companies doesn’t interested what structure you are using while developing.
Probably you know this formula : P=W/T  (P:Power – W:Work – T:Time) As you see here if you descrease the time so you may done with more Work. That means money! So, you see how MVC helps you.

Example:
As an example you can think like eyes of a human stands for view, brain stands for controller and neutral system of a body stands for model. You can imagine like when a person sees his friend eyes (view) tells this to the brain (controller). Brain wants to show smile to his friend. To make it possible brain tells your face’s neutral network that make the face smile. Then his face smiles  Hope it helped.

SSIS - Creating a Deployment Manifest

Using a Deployment Manifest in SSIS allows you to deploy a set of packages to a target location using a wizard for installing your packages.  The benefit to using it is the nice user interface that a wizard provides.  The disadvantage of using it is it’s lack of flexibility.  When using the Deployment Manifest keep in mind that it’s an all or nothing deployment, which means you cannot choose to just deploy one or two packages at a time from your SSIS project.  Using the Deployment Manifest will deploy all your packages that are in your project.  Creating the manifest file is a very simple process that I will walk you through.

Creating a Deployment Manifest

• With the Solution Explorer open Right-Click on the project name and click Properties
• This will open the Project Properties Pages 
• Select the Deployment Utility from the page
• Change the CreateDeploymentUtility property to True

After you’ve gone through these steps the next time you build your project it will create the file (YourProjectName).SSISDeploymentManifest.  This file is located in the same folder as your packages in the bin\Deployment folder.

If you run this file it will open the Package Installation Wizard that will allow you to deploy all your packages that were located in the project to a desired location.

Using WinSCP .NET Assembly from SQL Server Integration Services (SSIS)

• Installing
• Using from SSIS
• Example C# Script Task Code

Installing

First, you need to install the WinSCP .NET assembly.

You also need to install the assembly to the GAC1).

Using from SSIS

You use WinSCP .NET assembly from SSIS as any other .NET assembly:

• In Microsoft Visual Studio, in your “Integration Services Project”, choose your “SSIS Package” (e.g. the default Package.dtsx);
• Drag Script task from Toolbox onto Control flow view of the package;
• In the context menu of the task, choose Edit;
• On the Script task editor on Script page, click Edit script button;
• Visual Studio Tools for Applications is run to edit the script;
• Use Project > Add Reference > Browse to add reference to winscp.dll;
• Place your C# or VB.NET code into ScriptMain.Main method (see example below);
• Close Visual Studio Tools for Applications and Script task editor with OK button.

Example C# Script Task Code

using System;
using Microsoft.SqlServer.Dts.Runtime;
using Microsoft.SqlServer.Dts.Tasks.ScriptTask;
using System.AddIn;
using WinSCP;
 
namespace ST_5a30686e70c04c5a8a93729fd90b8c79.csproj
{
    [AddIn("ScriptMain", Version = "1.0", Publisher = "", Description = "")]
    public partial class ScriptMain : VSTARTScriptObjectModelBase
    {
        public void Main()
        {
            // Setup session options
            SessionOptions sessionOptions = new SessionOptions
            {
                Protocol = Protocol.Sftp,
                // To setup these variables, go to SSIS > Variables.
                // To make them accessible from the script task, in the context menu of the task,
                // choose Edit. On the Script task editor on Script page, select ReadOnlyVariables,
                // and tick the below properties.
                HostName = (string) Dts.Variables["User::HostName"].Value,
                UserName = (string) Dts.Variables["User::UserName"].Value,
                Password = (string) Dts.Variables["User::Password"].Value,
                SshHostKeyFingerprint = (string) Dts.Variables["User::SshHostKeyFingerprint"].Value
            };
 
            try
            {
                using (Session session = new Session())
                {
                    // As WinSCP .NET assembly has to be stored in GAC to be used with SSIS,
                    // you need to set path to WinSCP.exe explicitly, if using non-default location.
                    session.ExecutablePath = @"C:\winscp\winscp.exe";
 
                    // Connect
                    session.Open(sessionOptions);
 
                    // Upload files
                    TransferOptions transferOptions = new TransferOptions();
                    transferOptions.TransferMode = TransferMode.Binary;
 
                    TransferOperationResult transferResult;
                    transferResult = session.PutFiles(@"d:\toupload\*", "/home/user/", false, transferOptions);
 
                    // Throw on any error
                    transferResult.Check();
 
                    // Print results
                    bool fireAgain = false;
                    foreach (TransferEventArgs transfer in transferResult.Transfers)
                    {
                        Dts.Events.FireInformation(0, null, 
                            string.Format("Upload of {0} succeeded", transfer.FileName),
                            null, 0, ref fireAgain);
                    }
                }
 
                Dts.TaskResult = (int)DTSExecResult.Success;
            }
            catch (Exception e)
            {
                Dts.Events.FireError(0, null,
                    string.Format("Error when using WinSCP to upload files: {0}", e),
                    null, 0);
    
                Dts.TaskResult = (int)DTSExecResult.Failure;
            }
        }
    }
}

In the SSAS attribute relationships, what is the difference between Rigid and Flexible Relationships?

In simple terminology, by Rigid the following terms will come into our mind, something which is strict, something which is not so flexible, something which is fixed, firm or stiff and so on. So, even in Analysis Services, it has the same meaning, we use these for dimension attribute which do not change their values over a period of time, for example, if we take Time Dimension, the month May 2010 would always remain under the year 2010 (it’s true, you can believe me on thisJ, and any doubts, check calendar…), the same thing applies to a week in a month or a day in a week, the relationships never change.

So, with the same analogy, flexible is something that has a possibility of change (This is what we have to deal with most of the times, remember the rule, “Change is only constant”), in other terms, there is a possibility of members moving between dimension, taking a standard example for more clarity, let us take Organization -> Employee Department, an employee may be in Sales Department today, he or she can move to Marketing department, or vice versa or what ever other possibility… And another good example would be with respect to customer, customer’s address has a possibility to change, so this relationship between customer name and customer address is definitely going to be a Flexible one!!!

Now, with respect to analysis services, the default value for a relationship type property is flexible, so what does it really mean for us, flexible relationships require Analysis Services to drop and re-compute any existing aggregations during incremental dimension. If we change or define relationship between two attributes to Rigid, the analysis services by default takes the relationship as fixed and does not actually go and re-compute existing relationships and in other words lets the existing relationships remain without clearing them, thereby reducing the incremental process time.

In the above, the hard lines with dark arrows are the once representing the rigid relationships and the lighter once with transparent arrows are the flexible once.

If looked from other angle, with respect to MDX Query’s on the Cube with say… 30% aggregation, if we fire a MDX and say the numbers we need are not there in the aggregations present, so analysis services in turn has to calculate the numbers that we need from the details, now, it takes in to consideration all the relationships, suppose I need a number @ semester level which is not there in my current aggregations, so if I design a relationship in the time dimension like Year points to semester, semester point to quarter , quarter to month, month to week and week to day. So, here if analysis services calculate the required data for date level, by default it has the required information for returning the data that you need by doing proper summation. So, thus we can say that, the hierarchies with rigid relationships can be queried faster than those with flexible relationships. But, the issue that we would face is, changing any dependent attribute that has a rigid relationship within any hierarchy requires full process of the entire dimension.

Note:this should be present in a checklist for cube development process, because these settings really count for processing as well as query performance.