Reading directory:
1. requirement background (the Model metadata setting item should be bound to the View instead of the ViewModel) 1. 1. determine the scope of the problem domain (you can use DSL to manage the problem domain, provided that the domain model is locked) 2. migrate ViewModel settings to an external configuration file (extended Model metadata provider) 2. 1. implement the metadata provider (simple example) 1. requirement background (the Model metadata setting item should be bound to the View instead of the ViewModel)
Use ASP. NETMVC can be used to control how ViewModel is displayed in the View by setting simple Model metadata for medium and small websites. However, complicated application scenarios cannot be completed simply; the ViewModel of a large site is very large, which is really big beyond our imagination (of course there are historical reasons ), it is very tricky to present such a large display object on different pages. However, small websites do not often see ViewModel displayed on dozens of pages, generally, dozens of pages are similar;
In large e-commerce applications, a ViewModel on the UI Layer is used not only to present data, but also to communicate with remote SOA interfaces. If the structure is clear, ViewModel and DTO can be completely separated, however, sometimes we do need to consider extra performance overhead (sometimes we can only accept the legacy issues and the accumulation of technical debt will take long );
This article explains how to use ASP. when NETMVC is used to develop a large site, the metadata settings set in ViewModel call different metadata settings as different business views are different, simply put, we will not apply metadata control features directly on ViewModel, instead, you can bind the Model metadata settings item to a specific View to control the use of different metadata control items in different views, the metadata control feature is not bound to a specific ViewModel, but to a specific View, because only the View is the fixed content to be presented, and the ViewModel is the container used to share the display data items, I will use this article to explain how to design such a highly scalable ASP. use the NETMVC ViewModel structure;
1. 2. determine the scope of the problem domain (DSL can be used to manage the problem domain, provided that the domain model is locked)
When we consider using the configuration file to configure the required items, we need to first determine what needs to be configured; this requires us to first determine the problem domain, in fact, this is the method for DSL programming;
DSL: a language for a specific domain. It is mainly used to solve implementation problems in a specific domain. At the beginning, we can define this concept too large, it is wrong to solve all domain problems through DSL. DSL is actually a small part of domain problems, such: here we will migrate the ModelMetadata setting feature from the original definition on the ViewModel to the external.The main problem is to bind the ModelMetadata settings to the View.Instead of ViewModel;
Only by finding the correct problem domain can we design a DSL to fully express this problem domain. XML can well express the model of any specific domain structure, of course, you can design your own DSL;
Currently, the metadata control feature set in ViewModel applies to all views using this ViewModel.ModelMetadata domain <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Vc3Ryb25nPszhyKGz9sil0 + hybrid + bP8lZpZXe1xNSqyv2 + 3b/hybrid + pgltzybzcm9 "http://www.2cto.com/uploadfile/Collfiles/20140121/2014012109105286.jpg" alt = "\">
In the end, we will come up with a structure that meets actual needs;
2. migrate ViewModel settings to an external configuration file (extended Model metadata provider)To set items for successful migration, we must understand ASP. the principles of the Model metadata provider in NETMVC, so that we can change the original way of getting metadata into our own acquisition policy; the main functions of the Object Model of the metadata provider are divided into two parts (Here we only introduce the process of getting metadata ):
We need to replace the functional area of BuildModelMetadata with our own policy;
In this way, we can implant a group of powerful metadata providers into the ASP. NETMVC framework;
PassCustomModelMetadataProviderFactoryCreate a metadata provider object for obtaining any external type, such:CustomModelMetadataProviderWithDb(For database interfaces ),CustomModelMetadataProviderWithConfig(User configuration file ),CustomModelMetadataProviderWithService(Remote Service );
Migrate ModelMetadate cache data (memory optimization can be performed at a critical moment)
In ASP. NETMVC provides an internal ModelMetadata provider for obtaining a ViewModel. Through this portal, we can cache Model metadata in our own container, of course, the optimal cache location is the local process of the current application server. Here is the best cache location, the purpose of caching metadata is not to change the storage location, but to change the way and method it gets. In fact, there are many advantages, such as: Managing cache data in memory through tools, compress it, and so on, because you can control the process of getting metadata, which may be a saving-on-the-fly at the crucial moment. Here is just a little introduction to scalability. Of course, it depends on the specific requirements, however, this is indeed a good idea;
2. 1. Implement the metadata provider (simple example)View, ViewModel, and ModelMetadata ing design:
Using System. collections. generic; using System. linq; using System. web. mvc; namespace MvcApplication4.Seed {public enum View {HomePage_Index, HomePage_Edit} public enum ViewModel {Customer} public class ViewMappingModelMetadata {public View {get; set;} public ViewModel {get; set;} public ModelMetadata Metadata {get; set;} public class ViewMappingModelMetadataCollection: Dictionary
> {Private static ViewMappingModelMetadataCollection coll = new ViewMappingModelMetadataCollection (); static ViewMappingModelMetadataCollection () {// view under the Homepage --- interface from external files, here is just an example showing coll. add (View. homePage_Index, new List
(); Coll [View. homePage_Index]. add (new ViewMappingModelMetadata () {View = View. homePage_Index, ViewModel = ViewModel. customer, Metadata = new ModelMetadata (CustomModelMetadataProviderWithConfig. currentProvider, typeof (Models. customer), () => {return new Models. customer (). customerId;}, typeof (string), "CustomerId") {DisplayFormatString = @ "HomePage \ DisplayName: {0 }"}}); // view under EditCustomer-interface from external file. The following is an example showing coll. add (View. homePage_Edit, new List
(); Coll [View. homePage_Edit]. add (new ViewMappingModelMetadata () {View = View. homePage_Edit, ViewModel = ViewModel. customer, Metadata = new ModelMetadata (CustomModelMetadataProviderWithConfig. currentProvider, typeof (Models. customer), () => {return new Models. customer (). customerId;}, typeof (string), "CustomerId") {DisplayFormatString = @ "Edit \ DisplayName: {0}"});} public static ViewMappingMo DelMetadataCollection Current {get {return coll;} public ModelMetadata GetMetadataByView (View view, ViewModel model) {var metaList = from item in coll [view] where item. viewModel = model select item. metadata; return metaList! = Null & metaList. Count ()> 0? MetaList. LastOrDefault (): null ;}}}
These two sections need to be placed inside the framework. Here, they are written simply to demonstrate the Setting principle of their metadata;
System. Web. Mvc. ModelMetadataProvider:
Using System; using System. collections. generic; using System. web. mvc; namespace MvcApplication4.Seed {public class CustomModelMetadataProviderWithConfig: System. web. mvc. modelMetadataProvider {private static incluprovider = new CustomModelMetadataProviderWithConfig (); public static mmodelmetadataproviderwithconfig CurrentProvider {get {return provider;} public override IEnumerable
GetMetadataForProperties (object container, Type containerType) {throw new NotImplementedException (); // implement complex types and obtain attributes cyclically} public override ModelMetadata GetMetadataForProperty (Func
ModelAccessor, Type containerType, string propertyName) {throw new NotImplementedException (); // implement complex types and obtain attributes cyclically} public override ModelMetadata GetMetadataForType (FuncModelAccessor, Type modelType) {if (modelAccessor = null) return null; if (System. web. httpContext. current. session ["viewname"] = null) return null; var result = ViewMappingModelMetadataCollection. current. getMetadataByView (View) System. web. httpContext. current. session ["viewname"], (ViewModel) System. web. httpContext. current. session ["viewmodel"]); if (modelAccessor! = Null) result. Model = modelAccessor (). GetType (). GetProperty ("CustomerId"). GetValue (modelAccessor (); return result ;}}}
Customer model definition:
public class Customer{ public string CustomerId { get; set; }}
We have not applied any metadata control feature in the model, but we will see the effect on the interface;
View definition:
@ Model MvcApplication4.Models. Customer
Edit mode. @ Html. DisplayForModel (Model. CustomerId) |
@ Model MvcApplication4.Models. Customer
Display Mode. @ Html. EditorForModel (Model. CustomerId) |
These two models are presented;
The metadata we set automatically has been effective;
Author: Wang qingpei
Source:Http://blog.csdn.net/wangqingpei557
The copyright of this article is shared by the author and CSDN. You are welcome to repost it. However, you must retain this statement without the author's consent and provide the original article connection clearly on the article page. Otherwise, you will be entitled to pursue legal liability.