翻譯下首頁截圖的標籤:html
介紹:java
應用程序代碼庫的分層是一種被普遍接受的技術,可幫助下降複雜性並提升代碼重用性。爲了實現分層架構,ASP.NET樣板遵循域驅動設計的原則。ajax
域驅動設計 (DDD) 中有四個基本層:
表示層:爲用戶提供接口。使用應用程序層實現用戶交互。
應用程序層:在演示文稿層和域層之間起中介做用。協調業務對象以執行特定的應用程序任務。
領域層:包括業務對象及其規則。這是應用程序的核心。
基礎設施層:提供通用技術功能,主要使用第三方庫支持更高層。spring
總結:能夠點進去看,這裏只寫了不多的一部分,具體頁面還要一個很大的圖片,而且配有講解。數據庫
存儲庫模式"使用相似於集合的接口訪問域對象,在域和數據映射層之間進行中介"(馬丁·福勒)。設計模式
實際上,存儲庫用於對域對象(實體和值類型)執行數據庫操做。一般,每一個實體(或聚合根)都使用單獨的存儲庫。安全
在ASP.NET樣板,倉庫類實現IRepository<TEntity, TPrimaryKey> interface。ABP能夠自動建立爲每一個實體類型的默認庫。服務器
您能夠直接 inject IRepository<TEntity> (or IRepository<TEntity, TPrimaryKey>).一個示例應用服務使用的存儲庫中插入一個實體到數據庫:架構
地址:https://aspnetboilerplate.com/Pages/Documents/Repositoriesapp
總結具體請看頁面,演示了怎麼使用,和自定義倉庫(Repositories)
若是您已經知道依賴項注入、構造函數和屬性注入模式概念,則能夠跳到下一節。
維基百科說:"依賴注入是一種軟件設計模式,其中一個或多個依賴項(或服務)被注入或經過引用傳遞到從屬對象(或客戶端),並構成客戶端狀態的一部分。該模式將客戶端依賴項的建立與其本身的行爲分開,從而容許程序設計鬆散耦合,並遵循依賴項反轉和單一責任原則。它直接對比服務定位器模式,它容許客戶端了解他們用來查找依賴項的系統。
不使用依賴項注入技術,很難管理依賴項和開發模塊化且結構良好的應用程序。
在應用程序中,類彼此依賴。假設咱們有一個應用程序服務,它使用存儲庫將實體插入到數據庫中。在此狀況下,應用程序服務類依賴於存儲庫類。請參閱如下示例:
詳情地址:https://aspnetboilerplate.com/Pages/Documents/Dependency-Injection
總結:這裏面介紹了不少,具體能夠到網頁查看。
幾乎全部企業應用程序都在某個級別使用受權。受權用於檢查是否容許用戶在應用程序中執行某些特定操做。ASP.NET Boilerplate定義了基於權限的基礎結構來實現受權。
受權系統使用IPermissionChecker來檢查權限。雖然能夠用本身的方式實現它,但已在Module Zero項目中徹底實現了它。若是未實現,則使用NullPermissionChecker,它將全部權限授予全部人。
定義權限 爲每一個須要受權的操做定義了惟一權限。咱們須要先定義權限,而後再使用它。 ASP.NET Boilerplate設計爲模塊化的,所以不一樣的模塊能夠具備不一樣的權限。模塊應該建立一個從AuthorizationProvider派生的類,以定義其權限。受權提供者示例以下所示:
地址:https://aspnetboilerplate.com/Pages/Documents/Authorization
總結:詳情看原文,只翻譯了開頭,具體內容須要到頁面查看。
感受這個權限實現的很差用………………
鏈接和事務管理是使用數據庫的應用程序中最重要的概念之一。您須要知道什麼時候打開鏈接,什麼時候啓動事務以及如何處置鏈接,等等。...ASP.NET Boilerplate經過使用其工做單元系統來管理數據庫鏈接和事務。
ASP.NET Boilerplate打開一個數據庫鏈接(根據ORM提供程序的實現,它可能不會當即打開,而是在第一次使用數據庫時打開),並在輸入工做單位方法時開始事務。您能夠經過這種方法安全地使用鏈接。在該方法結束時,將提交事務並處置鏈接。若是該方法引起異常,則將回滾事務,並釋放鏈接。這樣,工做單元方法就是原子的(工做單元)。 ASP.NET Boilerplate自動完成全部這些操做。
若是一個工做單元方法調用另外一個工做單元方法,則二者都使用相同的鏈接和事務。首先輸入的方法管理鏈接和事務,而後其餘方法從新使用它。
若是未配置,則工做單元的默認IsolationLevel爲ReadUncommitted。使用工做單位選項能夠輕鬆配置它。
默認狀況下,某些方法是工做單元方法:
All MVC, Web API and ASP.NET Core MVC Controller actions.
All Application Service methods.
All Repository methods.
Assume that we have an application service method like the one below:
地址:https://aspnetboilerplate.com/Pages/Documents/Unit-Of-Work
總結:事務是很重要的一部份內容,詳情到具體頁面查看。
事務雖然複雜,可是通常框架使用起來都比較簡單(非分佈式事務)java的spring框架中使用事務就很簡單,加上一個註解就能夠了。
在應用程序中,應首先驗證輸入。輸入能夠由用戶或其餘應用程序發送。在Web應用程序中,驗證一般執行兩次:在客戶端和服務器端。客戶端驗證主要是爲了用戶體驗而實施的。最好先在客戶端中檢查表單,而後向用戶顯示無效字段。可是,服務器端驗證是不可避免的,而且更爲關鍵。
服務器端驗證一般在應用程序服務或控制器中實現(一般,全部服務都從表示層獲取數據)。應用程序服務方法應首先檢查(驗證)輸入,而後再使用它。 ASP.NET Boilerplate提供了用於自動驗證如下應用程序輸入的基礎結構:
All application service methods
All ASP.NET Core MVC controller actions
All ASP.NET MVC and Web API controller actions.
若是須要,請參見「禁用驗證」部分以禁用驗證。
ASP.NET Boilerplate支持數據註釋屬性。假設咱們正在開發一個Task應用程序服務,該服務將在任務得到輸入時用於建立任務,以下所示:
地址:https://aspnetboilerplate.com/Pages/Documents/Validating-Data-Transfer-Objects
總結:具體內容查看詳情頁面,這一部分的功能屬於基礎功能,必須瞭解熟悉。
維基百科:「審覈跟蹤(也稱爲審覈日誌)是與安全性相關的時間順序記錄,記錄集和/或記錄的目的地和記錄源,它們提供文件證據來證實特定操做在任什麼時候間都受到影響的活動順序。 ,過程或事件」。
ASP.NET Boilerplate提供了自動記錄應用程序內全部交互的基礎結構。它能夠記錄帶有調用者信息和參數的預期方法調用。
基本上,保存的字段包括:相關的租戶ID,呼叫者用戶ID,服務名稱(被調用方法的類),方法名稱,執行參數(序列化爲JSON),執行時間,執行持續時間(以毫秒爲單位),客戶端的IP地址,客戶端的計算機名稱和異常(若是該方法引起異常)。
有了這些信息,咱們不只知道誰進行了操做,並且還能夠評估應用程序的性能並觀察拋出的異常。此外,您能夠獲取有關應用程序使用狀況的統計信息。
審覈系統使用IAbpSession來獲取當前的UserId和TenantId。
默認狀況下,將自動審覈應用程序服務,MVC控制器,Web API和ASP.NET Core方法。
The Application Service, MVC Controller, Web API and ASP.NET Core methods are automatically audited by default.
關於IAuditingStore 審覈系統使用IAuditingStore保存審覈信息。雖然能夠用本身的方式實現它,但已在Module Zero項目中徹底實現了它。若是未實現,則使用SimpleLogAuditingStore並將審覈信息寫入日誌。
若要配置審覈,可使用模塊的PreInitialize方法中的Configuration.Auditing屬性。默認狀況下啓用審覈。您能夠以下所示禁用它:
地址:https://aspnetboilerplate.com/Pages/Documents/Audit-Logging
總結:具體查看詳情頁面,日誌是一個系統的基礎部分,只要開始正式使用,多多少少確定是要有日誌的,日誌是系統走向正規的必由之路。
服務器端 ASP.NET Boilerplate使用Castle Windsor的日誌記錄工具。它能夠與不一樣的日誌庫一塊兒使用:Log4Net,NLog,Serilog等。 Castle爲全部記錄器庫提供了通用接口。這樣,您就能夠獨立於特定的日誌記錄庫,之後能夠根據須要輕鬆地對其進行更改。
Log4Net是.NET最受歡迎的日誌記錄庫之一。 ASP.NET Boilerplate模板隨Log4Net一塊兒正確配置並可使用。僅存在一行與log4net依賴的代碼(如配置部分所示),所以您能夠輕鬆地將其更改成您喜歡的庫。
無論您選擇哪一個日誌庫,編寫日誌的代碼都是相同的(這要感謝Castle的通用ILogger接口)。
首先,咱們須要獲取一個Logger對象來編寫日誌。因爲ASP.NET Boilerplate強烈使用依賴項注入,所以咱們可使用屬性注入(或構造函數注入)模式輕鬆注入Logger對象。這是一個寫日誌行的示例類:
using Castle.Core.Logging; //1: Import Logging namespace public class TaskAppService : ITaskAppService { //2: Getting a logger using property injection public ILogger Logger { get; set; } public TaskAppService() { //3: Do not write logs if no Logger supplied. Logger = NullLogger.Instance; } public void CreateTask(CreateTaskInput input) { //4: Write logs Logger.Info("Creating a new task with description: " + input.Description); //TODO: save task to database... } }
地址:https://aspnetboilerplate.com/Pages/Documents/Logging
總結:具體查看詳情頁面,這個是系統的日誌,上一個是輸入驗證日誌;
本文檔適用於ASP.NET MVC和Web API。若是您對ASP.NET Core感興趣,請參閱ASP.NET Core文檔。
在Web應用程序中,一般在MVC Controller和Web API Controller操做中處理異常。發生異常時,會嚮應用程序用戶通知該錯誤以及可選緣由。
若是常規HTTP請求中發生錯誤,則會顯示錯誤頁面。若是AJAX請求中發生錯誤,則服務器將錯誤信息發送給客戶端,而後客戶端處理並顯示給用戶。
處理全部Web請求中的異常很繁瑣,而且很難保持DRY。 ASP.NET Boilerplate使此過程自動化。您幾乎不須要顯式處理異常。 ASP.NET Boilerplate處理全部異常,記錄它們,而後將適當的格式化響應返回給客戶端。它還在客戶端中處理這些響應,並向用戶顯示錯誤消息。
若要爲ASP.NET MVC控制器啓用錯誤處理,必須爲ASP.NET MVC應用程序啓用customErrors模式。
<customErrors mode="On" />
例如,若是您不想處理本地計算機上的錯誤,它也能夠是「 RemoteOnly」。請注意,這僅對於ASP.NET MVC控制器是必需的,而對於Web API控制器則不是必需的。
若是您已經在全局過濾器中處理異常,則它可能會隱藏異常。所以,ABP的異常處理可能沒法按預期工做。所以,若是執行此操做,請當心操做!
若是請求不是AJAX,則會顯示錯誤頁面。
想象一下,有一個MVC控制器動做會拋出一個任意異常:
public ActionResult Index() { throw new Exception("A sample exception message..."); }
最有可能的是,此操做將調用另外一種方法引起此異常。 ASP.NET Boilerplate處理此異常,記錄該異常並顯示「 Error.cshtml」視圖。您能夠自定義此視圖以顯示錯誤。這是一個示例錯誤視圖(ASP.NET Boilerplate模板中的默認「錯誤」視圖):
除非您明確拋出UserFriendlyException,不然ASP.NET Boilerplate會向用戶隱藏該異常的詳細信息並顯示標準(且可本地化)錯誤消息。
UserFriendlyException是一種特殊類型的異常,直接顯示給用戶。請參見下面的示例代碼:
public ActionResult Index() { throw new UserFriendlyException("Ooppps! There is a problem!", "You are trying to see a product that is deleted..."); }
ASP.NET Boilerplate將其記錄下來,而且不會隱藏異常:
若是要向用戶顯示特殊錯誤消息,只需拋出UserFriendlyException(或從中派生的異常)便可。
地址:https://aspnetboilerplate.com/Pages/Documents/Handling-Exceptions
總結:詳細信息,請查看具體頁面。異常處理的統一性比較困難,這一點能夠好好學習下。
開發適用於全球的應用程序,包括能夠本地化爲一種或多種語言的應用程序,須要本地化功能。 ASP.NET Boilerplate爲開發面向世界的本地化應用程序提供了普遍的支持。
首先要作的是聲明支持哪些語言。這是在模塊的PreInitialize方法中完成的,以下所示:
Configuration.Localization.Languages.Add(new LanguageInfo("en", "English", "famfamfam-flags gb", true)); Configuration.Localization.Languages.Add(new LanguageInfo("tr", "Türkçe", "famfamfam-flags tr"));
在服務器端,您能夠注入並使用ILocalizationManager。在客戶端,您可使用abp.localization JavaScript API來獲取全部可用語言以及當前語言的列表。 「 famfamfam-flags gb」(和「 famfamfam-flags tr」)只是一個CSS類,您能夠根據須要進行更改。而後,您能夠在UI中使用它來顯示相關標誌。
ASP.NET Boilerplate模板使用此係統向用戶顯示語言切換組合框。建立一個模板,並查看源代碼以獲取更多信息。
本地化文本能夠存儲在不一樣的源中。您甚至能夠在同一應用程序中使用多個源(若是您有多個模塊,則每一個模塊能夠定義一個單獨的本地化源,或者一個模塊能夠定義多個源)。 ILocalizationSource接口應由本地化源實現。而後將其註冊到ASP.NET Boilerplate的本地化配置。
每一個本地化源必須具備惟一的源名稱。有預約義的本地化源類型,以下所示。
本地化文本能夠存儲在XML文件中。 XML文件的內容以下所示:
<?xml version="1.0" encoding="utf-8" ?> <localizationDictionary culture="en"> <texts> <text name="TaskSystem" value="Task System" /> <text name="TaskList" value="Task List" /> <text name="NewTask" value="New Task" /> <text name="Xtasks" value="{0} tasks" /> <text name="CompletedTasks" value="Completed tasks" /> <text name="EmailWelcomeMessage">Hi, Welcome to Simple Task System! This is a sample email content.</text> </texts> </localizationDictionary>
XML文件必須是unicode(utf-8)。 culture =「 en」聲明此XML文件包含英語文本。對於文本節點; name屬性用於標識文本。您可使用value屬性或內部文本(如最後一個)來設置本地化文本的值。咱們爲每種語言建立一個單獨的XML文件,以下所示:
SimpleTaskSystem是此處的源名稱,而SimpleTaskSystem.xml定義了默認語言。當請求文本時,ASP.NET Boilerplate從當前語言的XML文件中獲取文本(它使用Thread.CurrentThread.CurrentUICulture查找當前語言)。若是當前語言不存在,它將從默認語言的XML文件中獲取文本。
XML文件能夠存儲在文件系統中,也能夠嵌入到程序集中。
對於文件系統存儲的XML,咱們能夠註冊XML本地化源,以下所示:
Configuration.Localization.Sources.Add( new DictionaryBasedLocalizationSource( "SimpleTaskSystem", new XmlFileLocalizationDictionaryProvider( HttpContext.Current.Server.MapPath("~/Localization/SimpleTaskSystem") ) ) );
這是在模塊的PreInitialize事件中完成的(有關更多信息,請參見模塊系統)。 ASP.NET Boilerplate在給定目錄中找到全部XML文件,並註冊本地化源。
對於嵌入式XML文件,咱們必須將全部本地化XML文件標記爲嵌入式資源(選擇XML文件,打開屬性窗口(F4),並將「構建操做」更改成「嵌入式資源」)。而後咱們能夠註冊本地化源,以下所示:
Configuration.Localization.Sources.Add( new DictionaryBasedLocalizationSource( "SimpleTaskSystem", new XmlEmbeddedFileLocalizationDictionaryProvider( Assembly.GetExecutingAssembly(), "MyCompany.MyProject.Localization.Sources" ) ) );
地址:https://aspnetboilerplate.com/Pages/Documents/Localization
總結:詳細信息請,查看具體頁面。本地化以前作過一次,都是寫死的,也是讀取xml文件。這裏能夠學習下abp的解決方案。
將類似的對象映射到另外一個對象是很常見的。由於一般兩個對象(類)可能具備彼此映射的相同/類似屬性,因此它也是繁瑣且重複的。想象一下下面的典型應用程序服務方法:
public class UserAppService : ApplicationService { private readonly IRepository<User> _userRepository; public UserAppService(IRepository<User> userRepository) { _userRepository = userRepository; } public void CreateUser(CreateUserInput input) { var user = new User { Name = input.Name, Surname = input.Surname, EmailAddress = input.EmailAddress, Password = input.Password }; _userRepository.Insert(user); } }
CreateUserInput是一個簡單的DTO類,而User是一個簡單的實體。咱們根據給定的輸入手動建立了一個User實體。用戶實體在實際應用程序中將具備更多屬性,而手動建立它會變得乏味且容易出錯。要向User和CreateUserInput添加新屬性時,咱們還必須更改映射代碼。
咱們可使用一個庫來自動處理咱們的映射。 AutoMapper是用於對象到對象映射的最佳庫之一。 ASP.NET Boilerplate定義了一個IObjectMapper接口以對其進行抽象,而後使用Abp.AutoMapper包中的AutoMapper實現此接口。
IObjectMapper是一個簡單的抽象,具備用於將一個對象映射到另外一個對象的Map方法。咱們能夠將上面的代碼替換爲:
public class UserAppService : ApplicationService { private readonly IRepository<User> _userRepository; private readonly IObjectMapper _objectMapper; public UserAppService(IRepository<User> userRepository, IObjectMapper objectMapper) { _userRepository = userRepository; _objectMapper = objectMapper; } public void CreateUser(CreateUserInput input) { var user = _objectMapper.Map<User>(input); _userRepository.Insert(user); } }
Map是獲取源對象並建立一個新的目標對象的簡單方法,該對象的類型聲明爲通用參數(此示例中爲User)。 Map方法具備將對象映射到現有對象的重載。假設咱們已經有一個User實體,並想使用一個對象來更新它的屬性:
public void UpdateUser(UpdateUserInput input) { var user = _userRepository.Get(input.Id); _objectMapper.Map(input, user); }
Abp.AutoMapper NuGet程序包(模塊)實現IObjectMapper並提供其餘功能。
首先,將Abp.AutoMapper NuGet軟件包安裝到您的項目中:
Install-Package Abp.AutoMapper
而後將AbpAutoMapperModule的依賴項添加到模塊定義類中:
[DependsOn(typeof(AbpAutoMapperModule))] public class MyModule : AbpModule { ... }
而後,您能夠安全地在代碼中注入並使用IObjectMapper。您還能夠在須要時使用AutoMapper本身的API。
在使用映射以前,AutoMapper要求您定義類之間的映射(默認狀況下)。您能夠查看AutoMapper本身的文檔以獲取有關映射的詳細信息。 ASP.NET Boilerplate使它變得更加簡單和模塊化。
大多數時候,您可能只想直接(和傳統上)映射類。在這種狀況下,可使用AutoMap,AutoMapFrom和AutoMapTo屬性。例如,若是要將上面的示例中的CreateUserInput類映射到User類,則可使用AutoMapTo屬性,以下所示:
[AutoMapTo(typeof(User))] public class CreateUserInput { public string Name { get; set; } public string Surname { get; set; } public string EmailAddress { get; set; } public string Password { get; set; } }
AutoMap屬性在兩個方向上映射兩個類。可是在此示例中,咱們僅須要從CreateUserInput映射到User,所以咱們使用了AutoMapTo
在某些狀況下,簡單映射可能不合適。例如,兩個類的屬性名稱可能略有不一樣,或者您可能但願在映射過程當中忽略某些屬性。在這種狀況下,您應該直接使用AutoMapper的API定義映射。 Abp.AutoMapper包定義了一個API,以使自定義映射更加模塊化。
假設咱們要忽略映射時的密碼,而且用戶具備稍微不一樣的命名電子郵件屬性。咱們能夠以下定義映射:
[DependsOn(typeof(AbpAutoMapperModule))] public class MyModule : AbpModule { public override void PreInitialize() { Configuration.Modules.AbpAutoMapper().Configurators.Add(config => { config.CreateMap<CreateUserInput, User>() .ForMember(u => u.Password, options => options.Ignore()) .ForMember(u => u.Email, options => options.MapFrom(input => input.EmailAddress)); }); } }
AutoMapper具備更多的對象間映射選項和功能。有關更多信息,請參見其文檔。
地址:https://aspnetboilerplate.com/Pages/Documents/Object-To-Object-Mapping
總結:其餘詳細信息,請查看具體頁面。
全文總結:
只是簡單翻譯了官網每一個標籤的很小一部份內容。具體還須要本身去官網一個主題一個主題看。
能夠挑選一些重要的主題先看,而後先看基本部分,而後再具體深刻;
而後擴大到其餘主題,而後深刻具體部分,而後擴展到細節部分;
abp內容很龐大,只能先學個大概了。