Shulou(Shulou.com)06/02 Report--

This article introduces what is the development model that .NET programmers should be familiar with, the content is very detailed, interested friends can refer to, hope to be helpful to you.

We always have such an experience: the most difficult and unchangeable part of a system is domain logic, and the easiest and most important thing to change is the way data is presented.

In various applications of Java, it can be said that MVC,J2EE runs through the concept of MVC everywhere, the development mode of android is also similar to MVC, and MVC structure is simply commonplace for people who have done Java applications. On the .NET side, because the various winform and ASP.NET project models provided by Microsoft (such as the petshop series) have well instilled the concept of "three layers" into the minds of .NET programmers, many .NET developers have to move their best artifacts such as IModel and IDAL when they do something.

In fact, MVC and the so-called "three-tier architecture" are two levels of things, the former is a structural model, while the latter is a hierarchical point of view.

It is a very strange thing that many people know about the "three layers" but do not know MVC. In fact, this can be attributed to the early development technologies of .NET, such as ASP.NET and winform, which make many people boast about the three layers but turn a blind eye to MVC or even know nothing about it. What is the page controller mode? Most of the people who do .NET have used winform and webform, this kind of xxxform is very intuitive to use, we want to make a program, ok, the easiest way is to drag and drop a few controls, and then write the handling logic of these UI events in something called code behind, add a lot of variables to record data and state, so that a program can be released. This kind of development method is actually quite efficient for the development of some small software systems, and later people see its disadvantages-once UI is modified, event handling will change, but the business is still that business, why modify non-UI code? So someone proposed "three layers". The simplest understanding is to divide the code in the original pile of event handling into business code and database access code and transfer it to other classes. If you do too much, the UI is called UI, the business code is called BLL, and the DAO is called DAL. This is the architecture:

What is familiar to J2EE developers is the following figure.

(note: these two pictures copy are written in daxnet)

What is MVC?

MVC is a classic structure, and its ideas have derived many variants such as MVP,MVVP. One of the traditional MVC structures (in the case of active MVC) is this:

For example, in web development (such as ASP.NET MVC or Java's web development), view is a pure web page or webservice. When a form is submitted / webservice or ajax is called, the data will be submitted to controller (of course, it may go through a variety of filterchain, listener, and so on) controller calls the appropriate business module to process the request, and the final result will update the display of View.

MVP

For frames that are not natural MVC

For ASP.NET/winform, although it can be modified to support the development of MVC structures (for example, through customized IHttpModule, IHttpHandler, and so on), these are considered evil martial arts in the eyes of enterprises (because it will lose many of the development features of xxxform, such as rapid development). Most of them use mvp mode. What is mvp? In fact, mvp is a variant of MVC. Because using winform or webform, form is always a problem that hinders MVC development. So good, we still use designer and codebehind, in fact, the quality of an architecture design depends on people rather than specific technology, as long as our OO is as good as page controller.

In MVP mode, we need to customize the IView, IPresenter and IModel corresponding to each View (web page or form). IView exposes UI and data binding interfaces to IPresenter, and IPresenter to IView exposes interfaces that need to be called when UI events are triggered. IPresenter calls the business interface according to the request passed by IView and operates UI according to the result. To take a simple example, a calculation of "Xerox?" The program. If we define IPresenter and IView this way,

Public interface IPresenter {IView View {get; set;} void CalculateResult ();} public interface IView {IPresenter Presenter {get; set;} void ShowResult (string result); int ValueOne {get;} int ValueTwo {get;}}

The implementation of IPresenter is as follows (IModel is simply removed here)

Presenter

Namespace ClientLibrary {public class Presenter: IPresenter {private IView _ view; public IView View {get {return _ view;} set {_ view = value; _ view.Presenter = this }} private static readonly string RESULT_FORMATTER = "{0} + {1}, the result is {2}"; public void CalculateResult () {if (_ view! = null) {var result = string.Format (RESULT_FORMATTER, _ view.ValueOne, _ view.ValueTwo, _ view.ValueOne + _ view.ValueTwo) _ view.ShowResult (result); this.A = 123;}} private int _ a; public int A {set {A = value;}}

The implementation of View is as follows (as an example, silverlight can be changed to something else)

MainPage

Namespace debug {public partial class MainPage: UserControl, IView {public MainPage () {InitializeComponent ();} private IPresenter _ presenter; private void btn_Click (object sender, RoutedEventArgs e) {if (_ presenter! = null) {_ presenter.CalculateResult () } # region hidden / * int total = 0; try {total = int.Parse (tb1.Text) + int.Parse (tb2.Text); MessageBox.Show ("calculation result:" + total.ToString ()) } catch (Exception ex) {MessageBox.Show ("wrong" + ex.ToString ());} finally {tb1.Text = string.Empty; tb2.Text = string.Empty } * / # endregion} public IPresenter Presenter {get {return _ presenter;} set {_ presenter = value } public void ShowResult (string result) {MessageBox.Show (result);} public int ValueOne {get {return int.Parse (tb1.Text);}} public int ValueTwo {get {return int.Parse (tb2.Text) }}

A very simple thing, it seems to be written into a little more stuff, but the advantage is obvious, is that it is very convenient to change view, there is no need to change your IPresenter, Presenter and business. This is the advantage that everything is an interface call and does not depend on the specific implementation.

You have to understand, MVVM.

For developers of the .NET platform, thanks to Microsoft, we have a more powerful model-MVVM. This should be regarded as a structure that people who do WPF/Silverlight applications must understand. WPF/silverlight naturally supports data binding and command binding (although sl is still weak in command binding), which makes it possible for us to use MVVM.

What is View? pure View has only xaml or comes with necessary logic code only related to View itself. ViewModel, you can understand it as an abstraction of the data on which View concrete content depends. In MVVM, View and ViewModel always have a binding relationship. Once the bound data in ViewModel changes, the data on View will change. On the contrary, it is also possible that, for example, if the content of your account password box changes, the data in the associated ViewModel will be automatically notified by the framework.

In wpf/silverlight, binding is done through xaml syntax (although you can choose to write in c # but it is not in line with the purpose of mvvm), and the notification mechanism of both sides of binding is done by a framework, that is, an artist who knows xaml and blend only needs to discuss with coder beforehand, "on which ViewModel is our xx and xx called the XXX attribute of the XXX attribute." After the problem, we can go our separate ways. So how to write ViewModel and how to bind to viewmodel in view? First, let's talk about ViewModel.

When it comes to ViewModel, you need to know the concepts of dependency attributes and dependent objects, which are the basis of wpf/silverlight, so don't say much. There are two ways to write ViewModel. * implement the INotifyPropertyChanged interface yourself and call the NotifyPropertyChanged event when the attribute changes.

To make it easier for us to define an abstract base class for ViewModelBase, then let other ViewModel inherit this base class.

ViewModelBase

Public abstract class ViewModelBase: System.ComponentModel.INotifyPropertyChanged, IDisposable {public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged (string propertyName) {if (PropertyChanged! = null) {var arg = new System.ComponentModel.PropertyChangedEventArgs (propertyName); PropertyChanged (this, arg) }} public virtual void Dispose () {}} DemoViewModel public class DemoViewModel: ViewModelBase {# region fields private string _ propertyA # endregion # region presentation properties public string PropertyA {get {return _ propertyA;} set {if (_ propertyA! = value) {_ propertyA = value Base.OnPropertyChanged ("PropertyA");} # endregion}

The second is to use DependencyObject and DependencyProperty.

PeopleItemViewModel

Public class PeopleItemViewModel: DependencyObject, IPeopleItemViewModel {public PeopleItemViewModel () {} public static readonly DependencyProperty SimpleUserDataProperty = DependencyProperty.Register ("SimpleUserData", typeof (SimpleUserData), typeof (PeopleItemViewModel)); public static readonly DependencyProperty RelativeSimpleUserDataProperty = DependencyProperty.Register ("RelativeSimpleUserData", typeof (ObservableCollection), typeof (PeopleItemViewModel)); public static readonly DependencyProperty AllSimpleUserDataProperty = DependencyProperty.Register ("AllSimpleUserData", typeof (ObservableCollection), typeof (PeopleItemViewModel)) Public SimpleUserData SimpleUserData {get {return (SimpleUserData) base.GetValue (SimpleUserDataProperty) } set {if (! base.CheckAccess ()) {Dispatcher.Invoke (new Action () = > {SimpleUserData = value) }));} else base.SetValue (SimpleUserDataProperty, value);}} public ObservableCollection RelativeSimpleUserData {get {return (ObservableCollection) base.GetValue (RelativeSimpleUserDataProperty) } set {if (! base.CheckAccess ()) {Dispatcher.Invoke (new Action () = > {RelativeSimpleUserData = value) });} else {base.SetValue (RelativeSimpleUserDataProperty, value); var collectionView = CollectionViewSource.GetDefaultView (value); collectionView.SortDescriptions.Add (new SortDescription ("Distance", ListSortDirection.Ascending)) } public ObservableCollection AllSimpleUserData {get {return (ObservableCollection) base.GetValue (AllSimpleUserDataProperty) } set {if (! base.CheckAccess ()) {Dispatcher.Invoke (new Action () = > {AllSimpleUserData = value) });} else {base.SetValue (AllSimpleUserDataProperty, value); var collectionView = CollectionViewSource.GetDefaultView (value); collectionView.SortDescriptions.Add (new SortDescription ("Distance", ListSortDirection.Ascending));}}

Bind ViewModel in View.

For convenience, we can put the required viewmode in the global resource dictionary in app.xaml.

Then on the Properties page of our vs view designer (the Chinese version shows "Properties"), we can choose to set the binding target for the binding source (including source and path, etc.) and the necessary value converters, and so on.

Although vs is very powerful, it is recommended to be familiar with the binding syntax of xaml. I don't seem to have such a convenient designer when I used vs2008 to do wpf.

Net programmers should be familiar with what the development model is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.