翻译下首页截图的标签: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内容很庞大,只能先学个大概了。