㈠ 如何改寫WebApi部分默認規則
namespace Xinchen.SOA.Server
{
public class Startup
{
public void Configuration(IAppBuilder appBuilder)
{
HttpConfiguration config = new HttpConfiguration();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "{controller}/{action}"
);
config.Services.Add(typeof(ValueProviderFactory), new MyValueProviderFactory());//自定義參數查找，實現第三個目標
config.Services.Replace(typeof(IHttpControllerSelector), new ControllerSelector(config));//自定義控制器查找，實現第一個目標
config.Services.Replace(typeof(IHttpActionSelector), new HttpActionSelector());//自定義Action查找，實現第二個目標
appBuilder.UseWebApi(config);
㈡ ASP.NET開發的管理系統是用框架好還是用母版頁好
模板維護起來方便快捷，
框架用於布局
模板其實有很多限制的，有時候確實挺不好用，如果母板頁里用form標簽了，內容頁就不可以用了。框架在後台頁面用的還挺爽的
框架需要網頁之間相互傳遞參數，模板頁不用。
看情況使用吧。
如果頁面間傳參少的話，用框架合適；
如果經常要傳許多參數並且頁面間交互頻繁，則可以選擇母版。
母板不能解決布面局部刷新問題,對用戶的體驗不好,點一下連接,整個頁面都要刷新.
感覺母板對開發人員來說是個好東西,對用戶來說,個人覺得不如框架,特別是用母板來導航時,很煩的.
我原來用母板導航的應用現在都改成框架了.
div不能跨框架，但模板頁每次都要全部重新載入，
兩者各有優劣，就看你在開發過程中的需求了
框架是瀏覽器窗口中的一個區域，一個框架對應一個單獨的HTML文檔，例如，一個頁面中有兩個框架實際上他有三個Html文檔，一個是框架集文件，另外兩個是框架文件。也就是說一個框架集是由多個框架頁面組成的。
模板可以創建具有相同布局的一系列文件，同時，模板最大的好處在於它的後期維護方便，可以快速的改變整個站點的布局和外觀。 模板是由可編輯區域和不可編輯區域兩部分組成，不可編輯區域包含所有頁面中共有的部分，可編輯區域是為頁面中不同部分的編輯設置的。
框架和模板都能統一頁面的風格，不過框架集設計的頁面是在同一個頁面中操作，只是不同的框架發生了變化，模板變化的整個網頁，只是它里邊包含一些共同的部分，通過設計模板來統一設計。
個人認為：模板主要為了統一頁面的風格。框架主要為了實現讓一個窗口顯示多個頁面。
另外，在使用中發現使用框架集好像整個頁面沒有滾動條，單個框架根據內容的多少可以設置顯示滾動條，但是整個窗口的內容沒法滾動，不知道有沒有方法實現。
㈢ ASP.NET除了做網站外，通常還可以做什麼
還能做控制台應用程序，和winform，什麼類型的軟體。學語言先用控制台應用程序寫吧，了解語言的用法就好。其它的都一樣，學asp.net就是了解下控制項就好了，同理winform也是
㈣ 開發一套小型且完整的數據管理系統需要哪些知識
mongodb 做資料庫nodejs寫服務端html + css + js 寫瀏覽器端需要哪些知識很難說得准確，業務是一定要懂的，基本的技術如各環境的api，js語言，頁面設計與重構也是必須會的，再往上說，整個系統的架構設計，底層數據結構設計，演算法設計，其實不是需要哪些知識，而是，你會的就用得上，如果你會，我想大數據，機器學習都是可以用上的。
㈤ 如何改寫WebApi部分默認規則
如何改寫WebApi部分默認規則
如何改寫WebApi部分默認規則為什麼要改最近公司在推廣SOA框架，第一次正經接觸這種技術（之前也有但還是忽略掉吧），感覺挺好，就想自己也折騰一下，實現一個簡單的SOA框架
用過mvc進行開發，印象之中WebApi和Mvc好像是一樣的，帶著這樣的預設開始玩WebApi，然後被虐得找不到著北。
被虐的原因，是Mvc和WebApi在細節上差別還是有點大，例如：
在Mvc中，一個Controller中的所有公共方法一般情況下可以響應POST方法，而WebApi中不行在Mvc中，一個Action方法中的參數即可來自Url，也可以來自Form，而WebApi中不是這樣，具體的規則好像是除非你在參數中加了[FromBody]，否則這個參數永遠也無法從Form中獲取這是這兩種技術我知道的最大的差別，其他的沒發現或者說是沒注意，也有可能這些差別是因為我不會用，畢竟接觸WebApi時間不長。如果我有些地方說錯了，請指正。
就這兩個不同點，我查了很多資料，也沒有辦法解決，第一個還好，加個特性就行了，第二個的話好像就算加了[FromBody]也還是不行，感覺就是一堆限制。接著，既然這么多讓我不爽的地方，那我就來改造它吧。
改造的目標，有以下幾個：
不再限制控制器必須以Controller結尾，其實這個並不是必須，只是被限制著確實不太舒服所有方法可以響應所有的請求方法，如果存在方法名相同的方法，那麼才需要特性來區分Action中的參數優先從Url中獲取，再從Body中獲取，從Body中獲取的時候，優先假設Body中的數據是表單參數，若不是則將Body中的數據當作json或xml數據進行獲取定下了目標之後，感覺微軟為什麼要這樣設計WebApi呢，或許它有它的道理。
目標好定，做起來真是頭大，一開始想參考公司的SOA框架的實現，但因為我用了OWIN技術來進行宿主，而看了公司的框架好像不是用的這個，總之就是看了半天沒看懂應該從哪個地方開始，反而是越看越糊，畢竟不是完全一樣的技術，所以還是自己弄吧。
OK，廢話了這么多，進入正題吧。首先來一個鏈接，沒了這個文章我就不可能改造成功：http://www.cnblogs.com/beginor/archive/2012/03/22/2411496.html
OWIN宿主其實這個網上很多，我主要是為了貼代碼，不然的話下面幾小節寫不下去
[assembly: OwinStartup(typeof(Startup))]//這句是在IIS宿主的時候使用的，作用是.Net會查找Startup類來啟動整個服務 namespace Xinchen.SOA.Server { public class Startup { public void Configuration(IAppBuilder appBuilder) { HttpConfiguration config = new HttpConfiguration(); config.Routes.MapHttPRoute( name: "DefaultApi", routeTemplate: "{controller}/{action}" ); config.Services.Add(typeof(ValueProviderFactory), new MyValueProviderFactory());//自定義參數查找，實現第三個目標 config.Services.Replace(typeof(IHttpControllerSelector), new ControllerSelector(config));//自定義控制器查找，實現第一個目標 config.Services.Replace(typeof(IHttpActionSelector), new HttpActionSelector());//自定義Action查找，實現第二個目標 appBuilder.UseWebApi(config); } } } 省略了部分不太重要的代碼，Services.Add和Replace從字面就能明白是什麼意思，但我沒有試過是否必須要像上面那樣寫才行
對控制器的限制public class ControllerSelector : IHttpControllerSelector { HttpConfiguration _config; IDictionary<string, HttpControllerDescriptor> _desriptors = new Dictionary<string, HttpControllerDescriptor>(StringComparer.OrdinalIgnoreCase); public ControllerSelector(HttpConfiguration config) { _config = config; } void InitControllers() { if (_desriptors.Count <= 0) { lock (_desriptors) { if (_desriptors.Count <= 0) { var assemblies = AppDomain.CurrentDomain.GetAssemblies().Where(x => !x.GlobalAssemblyCache && !x.IsDynamic); var controllerTypes = new List<Type>(); foreach (var ass in assemblies) { controllerTypes.AddRange(ass.GetExportedTypes().Where(x => typeof(ApiController).IsAssignableFrom(x))); } var descriptors = new Dictionary<string, HttpControllerDescriptor>(); foreach (var controllerType in controllerTypes) { var descriptor = new HttpControllerDescriptor(_config, controllerType.Name, controllerType); _desriptors.Add(descriptor.ControllerName, descriptor); } } } } } public IDictionary<string, HttpControllerDescriptor> GetControllerMapping() { InitControllers(); return _desriptors; } public System.Web.Http.Controllers.HttpControllerDescriptor SelectController(System.Net.Http.HttpRequestMessage request) { InitControllers(); var routeData = request.GetRouteData(); var controllerName = Convert.ToString(routeData.Values.Get("controller")); if (string.IsNullOrWhiteSpace(controllerName)) { throw new ArgumentException(string.Format("沒有在路由信息中找到controller")); } return _desriptors.Get(controllerName); } } 這個其實比較簡單，測試中WebApi好像沒調用GetControllerMapping方法，直接調用了SelectController方法，最後一個方法中有兩個Get方法調用，Get只是把從字典獲取值的TryGetValue功能給封裝了一下，InitControllers方法是從當前所有的程序集中找繼承了ApiController的類，找到之後緩存起來。這段代碼整體比較簡單。
對Action的限制public class HttpActionSelector : IHttpActionSelector { public ILookup<string, HttpActionDescriptor> GetActionMapping(HttpControllerDescriptor controllerDescriptor) { var methods = controllerDescriptor.ControllerType.GetMethods(); var result = new List<HttpActionDescriptor>(); foreach (var method in methods) { var descriptor = new ReflectedHttpActionDescriptor(controllerDescriptor, method); result.Add(descriptor); } return result.ToLookup(x => x.ActionName); } public HttpActionDescriptor SelectAction(HttpControllerContext controllerContext) { var actionDescriptor = new ReflectedHttpActionDescriptor(); var routeData = controllerContext.RouteData; object action = string.Empty; if (!routeData.Values.TryGetValue("action", out action)) { throw new HttpResponseException(controllerContext.Request.CreateErrorResponse(System.Net.HttpStatusCode.NotFound, "在路由中未找到action")); } string actionName = action.ToString().ToLower(); var methods = controllerContext.ControllerDescriptor.ControllerType.GetMethods().Where(x => x.Name.ToLower() == actionName); var count = methods.Count(); MethodInfo method = null; switch (count) { case 0: throw new HttpResponseException(controllerContext.Request.CreateErrorResponse(System.Net.HttpStatusCode.NotFound, "在控制器" + controllerContext.ControllerDescriptor.ControllerName + "中未找到名為" + actionName + "的方法")); case 1: method = methods.FirstOrDefault();
break; default: var httpMethod = controllerContext.Request.Method; var filterdMethods = methods.Where(x => { var verb = x.GetCustomAttribute<AcceptVerbsAttribute>(); if (verb == null) { throw new HttpResponseException(controllerContext.Request.CreateErrorResponse(System.Net.HttpStatusCode.NotFound, "在控制器" + controllerContext.ControllerDescriptor.ControllerName + "中找到多個名為" + actionName + "的方法，請考慮為這些方法加上AcceptVerbsAttribute特性")); } return verb.HttpMethods.Contains(httpMethod); }); if (filterdMethods.Count() > 1) { throw new HttpResponseException(controllerContext.Request.CreateErrorResponse(System.Net.HttpStatusCode.NotFound, "在控制器" + controllerContext.ControllerDescriptor.ControllerName + "中找到多個名為" + actionName + "的方法，並且這些方法的AcceptVerbsAttribute都含有" + httpMethod.ToString() + "，發生重復")); } else if (filterdMethods.Count() <= 0) { throw new HttpResponseException(controllerContext.Request.CreateErrorResponse(System.Net.HttpStatusCode.NotFound, "在控制器" + controllerContext.ControllerDescriptor.ControllerName + "中找到多個名為" + actionName + "的方法，但沒有方法被配置為可以響應" + httpMethod.ToString() + "請求")); } method = filterdMethods.FirstOrDefault();
break; } return new ReflectedHttpActionDescriptor(controllerContext.ControllerDescriptor, method); } } GetActionMapping方法很簡單，從控制器類型中找到所有的Action方法並返回
SelectAction方法相對復雜，其實就是第二個目標的邏輯，代碼看起來比較多其實並有很難的地方。
對Action的參數的限制這一塊比較難，我試了很久才成功，而且還有坑
public class ActionValueBinder : DefaultActionValueBinder { protected override HttpParameterBinding GetParameterBinding(HttpParameterDescriptor parameter) { ParameterBindingAttribute parameterBinderAttribute = parameter.ParameterBinderAttribute; if (parameterBinderAttribute == null) { parameterBindingRules = parameter.Configuratio
㈥ c# webapi Session
沒使用過，
既然你的程序被設計為 webapi，或者SOA架構，你應該拋棄這種設計，讓第三方庫 緩存 或者 本地緩存 做為驗證保存。如果是設計為分布式，你需要一個中央緩存管理這些信息，
㈦ 怎麼改寫WebApi部分默認規則
怎麼改寫WebApi部分默認規則
如何改寫WebApi部分默認規則
為什麼要改
最近公司在推廣SOA框架，第一次正經接觸這種技術（之前也有但還是忽略掉吧），感覺挺好，就想自己也折騰一下，實現一個簡單的SOA框架
用過mvc進行開發，印象之中WebApi和Mvc好像是一樣的，帶著這樣的預設開始玩WebApi，然後被虐得找不到著北。
被虐的原因，是Mvc和WebApi在細節上差別還是有點大，例如：
在Mvc中，一個Controller中的所有公共方法一般情況下可以響應POST方法，而WebApi中不行
在Mvc中，一個Action方法中的參數即可來自Url，也可以來自Form，而WebApi中不是這樣，具體的規則好像是除非你在參數中加了[FromBody]，否則這個參數永遠也無法從Form中獲取
這是這兩種技術我知道的最大的差別，其他的沒發現或者說是沒注意，也有可能這些差別是因為我不會用，畢竟接觸WebApi時間不長。如果我有些地方說錯了，請指正。
就這兩個不同點，我查了很多資料，也沒有辦法解決，第一個還好，加個特性就行了，第二個的話好像就算加了[FromBody]也還是不行，感覺就是一堆限制。接著，既然這么多讓我不爽的地方，那我就來改造它吧。
改造的目標，有以下幾個：
不再限制控制器必須以Controller結尾，其實這個並不是必須，只是被限制著確實不太舒服
所有方法可以響應所有的請求方法，如果存在方法名相同的方法，那麼才需要特性來區分
Action中的參數優先從Url中獲取，再從Body中獲取，從Body中獲取的時候，優先假設Body中的數據是表單參數，若不是則將Body中的數據當作json或xml數據進行獲取
定下了目標之後，感覺微軟為什麼要這樣設計WebApi呢，或許它有它的道理。
目標好定，做起來真是頭大，一開始想參考公司的SOA框架的實現，但因為我用了OWIN技術來進行宿主，而看了公司的框架好像不是用的這個，總之就是看了半天沒看懂應該從哪個地方開始，反而是越看越糊，畢竟不是完全一樣的技術，所以還是自己弄吧。