spring.net 到底有什么好处?我还是没找到它好处?

以下是我网上找的资料,感谢原著。但我还是搞不明白spring.net 带来的好处,可能真是像网上说的那样,超大项目才能体会。

你现在只是学习阶段不能体会到spring真正的好处
如果你开发一个项目的话(加入给予SSH框架的) ,项目中的类是巨多了,有许多的aciton类、actionform类 有许多的业务逻辑层类 有DAO
当然如果你不用spring去配置也行,用到某个类时可以直接new,但是这样做出来的项目维护起来很难,首先两个之间你用new的话
那么这两个类之间的耦合度就高了 
而用spring以后,你不用在关心这等等的一切 ,他全部给你摆到配置文件中 
你有一个UserAction ,OK!在spring中你就只要配置一下 
<bean id="userAction" class="*.UserAction"></bean> 
如果UserAction类中用到UserManager类的话,你也不用直接在程序中new了 ,你只需在程序中提供一个UserManager的set方法
然后在配置文件中直接配置下就完成了 
<bean id="userManager" class="*.UserManager">
<property name="userManager" ref="UserManager"/>
</bean>
Spring就可以给你同意管理这些所有的aciton 类 所有的业务逻辑类 等等
当你项目写好部署到服务器运行时,服务器一启动,就会自动读取spring的配置文件,然后把你配置的这些类全部实例化好..
把你写的对象类全部给导出成数据库表,而不向你学hibernate的时候 写好的对象类还要自己写一个导出程序 给他导出成数据库表
如果你写过项目就能体会到他的妙处,很强大  .....................


————————————————————————————————————————————————————————————————————————

在SSH框架中使用Spring的好处

在SSH框假中spring充当了管理容器的角色。我们都知道Hibernate用来做持久层,因为它将JDBC做了一个良好的封装,程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的,他它负责调用业务逻辑serivce层。所以SSH框架的流程大致是:Jsp页面----Struts------Service(业务逻辑处理类)---Hibernate(左到右)
  struts负责控制Service(业务逻辑处理类),从而控制了Service的生命周期,这样层与层之间的依赖很强,属于耦合。这时,使用spring框架就起到了控制Action对象(Strus中的)和Service类的作用,两者之间的关系就松散了,Spring的Ioc机制(控制反转和依赖注入)正是用在此处。
     Spring的Ioc(控制反转和依赖注入)
     控制反转:就是由容器控制程序之间的(依赖)关系,而非传统实现中,由程序代码直接操控 
     依赖注入:组件之间的依赖关系由容器在运行期决定 ,由容器动态的将某种依赖关系注入到组件之中 。
   从上面我们不难看出:从头到尾Action仅仅是充当了Service的控制工具,这些具体的业务方法是怎样实现的,他根本就不会管,也不会问,他只要知道这些业务实现类所提供的方法接口就可以了。而在以往单独使用Struts框架的时候,所有的业务方法类的生命周期,甚至是一些业务流程都是由Action来控制的。层与层之间耦合性太紧密了,既降低了数据访问的效率又使业务逻辑看起来很复杂,代码量也很多。,Spring容器控制所有Action对象和业务逻辑类的生命周期,由于上层不再控制下层的生命周期,层与层之间实现了完全脱耦,使程序运行起来效率更高,维护起来也方便。
  使用Spring的第二个好处(AOP应用):
    事务的处理:
   在以往的JDBCTemplate中事务提交成功,异常处理都是通过Try/Catch 来完成,而在Spring中。Spring容器集成了TransactionTemplate,她封装了所有对事务处理的功能,包括异常时事务回滚,操作成功时数据提交等复杂业务功能。这都是由Spring容器来管理,大大减少了程序员的代码量,也对事务有了很好的管理控制。Hibernate中也有对事务的管理,hibernate中事务管理是通过SessionFactory创建和维护Session来完成。而Spring对SessionFactory配置也进行了整合,不需要在通过hibernate.cfg.xml来对SessionaFactory进行设定。这样的话就可以很好的利用Sping对事务管理强大功能。避免了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的Try/Catch操作。这些也就是Spring中的AOP(面向切面编程)机制很好的应用。一方面使开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng  AOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度


---------------------------------------------------------------------------------
再锻炼一下自己的解释问题的能力。 

ioc是一种类的实现方法,而不是关于接口设计的方法。 
它的关注点是 我怎么实现这个类最简单灵活 。 
而不关注别人如何调用我的模块最简单明了。 


设计模块A的实现,当它需要从另外一个模块得到功能B的时候,基本有两种选择: 

1。直接静态地找到实现B的模块。自己用new创建B的对象,或者通过一个静态工厂,service locator。都属于这个范畴。 
这种情况其实很常见。比如,我内部需要一个查找表,自己直接new一个HashMap就好了,谁耐烦从外界ioc进来一个Map这么麻烦? 
或者,大家平时都自己new一个StringBuffer吧?没人从外面ioc吧? 

采用这个方法的前提是: 
  a.  自己具体选取哪个模块对外界完全透明。比如,我用HashMap还是TreeMap,只影响效率,但是不影响我这个模块对调用者承诺的语义。 
  b. 或者,实现这个功能的B模块已经是一个100%的标准。 

这两个前提满足任何一个,都没必要也不应该ioc。 


2。从外界动态接收一个实现功能B的实例。 
这就是ioc了。不过,ioc本身并不规定注射进来的就必须是一个接口。注射一个具体类,抽象类也是ioc。只不过一般来说,根据接口编程原则,用接口更加好。 

采用它的前提是: 
  a. 不同的B的实现会影响A的语义。而在设计A的时候我们不能决定选择哪个实现。 
  b. 或者,实现B的模块没有一个标准,考虑到移植性的问题,可以用ioc来把责任推诿到其它模块。 


采用ioc的几个注意点: 
  a. 最好是要ioc进来的组件是immutable的,没有状态。这样的ioc最简单。 

  b. 如果需要状态变化,那么关于状态变化的语义一定要定义清楚。调用者和被调用者各自改变组件的状态都有什么结果要明确。 

  c. 如果模块内部需要自己控制对象的生命期,此时就要ioc进来一个工厂。(注意,工厂也是一个普通的java对象,自然也可以ioc。同理,工厂的工厂,工厂的工厂的工厂,都可以ioc。不要一看见工厂字样就觉得和ioc抵触。工厂不过是一个有着一个create()函数的对象而已) 

  d. 不要杞人忧天,想着别人如何把这个对象给你。OO是一个职责分配的体系。你该关心的是如何用这个组件实现你自己的功能,至于组件怎样来,不是你的责任,你不要管也不应该管。 

  e. 要学会偷懒和推卸责任。通过把寻找对象的职责推诿出去,你可以保证少挨骂。如果组装者组装了一个错误的组件,那么责任在他,你大可以跳起脚来骂。而如果你自己越俎代庖弄错了,责任则全部在你。 

  f.  即使组装者也是你自己,ioc至少保证了改正错误或者扩展功能的代价最小化。你需要修改的只是组装部分,而不是包含者业务逻辑的业务对象。 



好了。说完怎么用ioc实现模块。再来说怎么使用一个ioc设计的模块。 

正如frankensteinlin所说,调用者直接调用一个ioc模块并不是最简单最直观的。 
new AImpl(new BImpl()).f() 
明显比new DefaultAImpl().f()要麻烦。 

但是,很多时候调用者自己也不必惹这个麻烦的。我的模块C如果需要A的功能,大可以继续推诿责任,让别人给我一个A的实例就是。 

如此,创建C的时候就变成: 
Java代码   收藏代码
  1. new CImpl(new AImpl(new BImpl(););););;  



这样层层推诿,最终会有一个组装者,他把所有的对象组装责任接过来,他的唯一责任就是组装各个组件,而没有业务逻辑方面的职责。 


不过,我要反对age0以及很多其它人的是: 

ioc并不是说系统只能有一个终极对象组装者(比如配置文件什么的)。 

系统是模块套模块的。有时候模块A不能决定,推诿出去,模块B不能决定,也推诿出去,但是模块C可能发现此时选择AImpl1, 还是AImpl2, 选择BImpl1还是BImpl2对它要实现的语义来说已经符合上面说的不用ioc的前提了,那么此时,对象C就可以作为局部的A和B的组装者,没必要把这个职责再推诿出去了。 

而这些组装策略也不是一言堂。根据不同的组装者的需要,可以选择直接new,静态工厂,service locator,或者配置文件。 

这里面没有东风压倒西风的问题,完全是根据具体需要选择合适的组装方法。 



最后,重提java.io。 


当sun设计BufferedReader的时候,虽然从它的功能上你可以叫它decorator,但是它的设计方法却无疑是ioc的。 
它从外界接受一个Reader实例,然后对之进行缓存处理。 
它不对输入的Reader到底是哪个Reader做任何假设或者要求。它只是简单地在构造函数里宣称需要一个Reader。 


然后,当我们的一个模块X使用BufferedReader的时候,可能我们已经知道需要给它一个什么Reader,此时,就没必要继续ioc了,在这个X模块里,ioc到此为止,我们直接组装对象就好了。 

有没有可能一个Reader要在终极的配置文件里由deploymentor决定采用哪个实现呢?理论上应该也有可能,只不过,我至今还没有遇到过。


---------------------------------------------------------------------------------------

举一个实际的例子吧。 

我们先后为某银行做了2套系统,等第二套快做完的时候,银行说虽然是2套,但我想用统一的用户管理,想想这也是合理,一个单位的员工没有必要在两个地方管理。所以就把有关用户/权限管理的数据单独拎出来了。 

这时候我的系统就要访问2个数据源了,怎么办呢? 

在Spring的配置里增加一个DataSource指向新的数据源,把有关用户数据访问的DAO的Datasource全改一遍,OK!十分钟搞定。 

而前一套系统呢,2年多前做的了,设计得没有这么好,改动太大,最终只能放弃,还是把数据放在它那里,由后一套系统的Datasource指过去。 

这大约就是IOC的好处了。 
前面也有人说过了,在需要Ioc的地方才用,不能全都用,这也是一个原则。前面的讨论有时就险入以偏概全的问题,一说Ioc,好像就必须全部用似的。

Spring.NET是一个应用程序框架,其目的是协助开发人员创建企业级的.NET应用程序。它提供了很多方面的功能,比如依赖注入、面向方面编程(AOP)、数据访问抽象及ASP.NET扩展等等。Spring.NET以Java版的Spring框架为基础,将Spring.Java的核心概念与思想移植到了.NET平台上。 第一章 序言 第二章 简介 2.1.概述 2.2.背景 2.3.模块 2.4.许可证信息 2.5.支持 第三章 背景 3.1.控制反转 第一部分 核心技术 第四章 对象、对象工厂和应用程序上下文 4.1.简介 4.2.IObjectFactory,IApplicationContext和IObjectDefinition接口介绍 4.2.1.The IObjectFactory和IApplicationContext 4.2.2.对象定义 4.2.3.对象的创建 4.2.3.1.通过构造器创建对象 4.2.3.2.通过静态工厂方法创建对象 4.2.3.3.通过实例工厂方法创建对象 4.2.4.泛型类的对象创建 4.2.4.1.通过构造器创建泛型类的对象 4.2.4.2.通过静态工厂方法创建泛型类的对象 4.2.4.3.通过实例工厂方法创建泛型类的对象 4.2.5.对象标识符(id和name) 4.2.6.Singleton和Prototype 4.3.属性,协作对象,自动装配和依赖检查 4.3.1.设置对象的属性和协作对象 4.3.2.构造器参数解析 4.3.2.1.根据参数类型匹配构造器参数 4.3.2.2.根据参数索引匹配构造器参数 4.3.2.3.根据名称匹配构造器参数 4.3.3.详细讨论对象属性和构造器参数 4.3.3.1.设置空值 4.3.3.2.设置集合值 4.3.3.3.设置泛型集合的值 4.3.3.4.设置索引器属性 4.3.3.5.内联对象定义 4.3.3.6.idref节点 4.3.3.7.引用协作对象 4.3.3.8.value和ref节点的简短格式 4.3.3.9.复合属性名 4.3.4.方法注入 4.3.4.1.查询方法注入 4.3.4.2.替换任意方法 4.3.5.引用其他对象或类型的成员 4.3.5.1.使用对象或类的属性值进行注入 4.3.5.2.使用字段值进行注入 4.3.5.3.使用方法的返回值进行注入 4.3.6.IFactoryObject接口的其它实现 4.3.6.1.Log4Net 4.3.7.使用depends-on 4.3.8.自动装配协作对象 4.3.9.检查依赖项 4.4.类型转换 4.4.1.枚举类型的转换 4.4.2.内置的类型转换器 4.4.3.自定义类型转换器 4.4.3.1.使用CustomConverterConfigurer类 4.5.自定义对象的行为 4.5.生命周期接口 4.5.1.1.IInitializingObject接口和init-method属性 4.5.1.2.IDisposable接口和destroy-method属性 4.5.2.让对象了解自己的容器 4.5.2.1.IObjectFactoryAware接口 4.5.2.2.IObjectNameAware接口 4.5.3.IFactoryObject接口 4.6.抽象与子对象定义 4.7.与IObjectFactory接口交互 4.7.1.获得IFactoryObject对象本身,而非其产品 4.8.使用IObjectPostProcessor接口自定义对象 4.9.使用IObjectFactoryPostProcessor定制对象工厂 4.9.1.PropertyPlaceholderConfigurer类 4.9.1.1.使用环境变量进行替换 4.9.2.PropertyOverrideConfigurer类 4.10.使用alias节点为对象添加别名 4.11.IApplicationContext简介 4.12.配置应用程序上下文 4.12.1.注册自定义解析器 4.12.2.创建自定义资源处理器 4.12.3.配置类型别名 4.12.4.注册类型转换器 4.13.IApplicationContext接口的扩展功能 4.13.1.上下文继承 4.13.2.使用IMessageSource接口 4.13.3.在Spring.NET内部使用资源 4.13.4.松耦合事件模型 4.13.5.IApplicationContext的事件通知 4.14.定制IApplicationContex中对象的行为 4.14.1.IApplicationContextAware标识接口 4.14.2.IObjectPostProcessor接口 4.14.3.IObjectFactoryPostProcessor接口 4.14.4.PropertyPlaceholderConfigurer类 4.15.从其它文件中导入对象定义 4.16.服务定位器访问 第五章. IObjectWrapper接口和类型转换 5.1.简介 5.2.使用IObjectWrapper接口管理对象 5.2.1.读、写普通及嵌套的属性 5.2.2.其它功能 5.3.类型转换 5.3.1.转换枚举类型 5.4.内置类型转换器 第六章. IResource接口 6.1.简介 6.2.IResource接口 6.3.内置的IResource实现类 6.4.IResourceLoader接口 6.5.IResourceLoaderAware接口 6.6.应用程序上下文和IResource路径 第七章. 多线程和并发操作 7.1.简介 7.2.线程本地存储 7.3.同步基础 7.3.1.ISync 7.3.2.SyncHolder 7.3.3.Latch 7.3.4.Semaphore 第八章. 对象池 8.1.简介 8.2.接口和实现 第九章. Spring.NET杂记 9.1.简介 9.2.PathMatcher 9.2.1.通用规则 9.2.2.匹配文件名 9.2.3.匹配子目录 9.2.4.大小写需要考虑,斜线可以任意 第十章. 表达式求值 10.1.简介 10.2.表达式求值 10.3.语言参考 10.3.1.文字表达式 10.3.2.属性,数组,列表,字典,索引器 10.3.2.1.定义内联的数组、列表和词典 10.3.3.方法 10.3.4.操作符 10.3.4.1.关系操作符 10.3.4.2.逻辑操作符 10.3.4.3.算术运算符 10.3.5.赋值 10.3.6.表达式列表 10.3.7.类型 10.3.8.类型注册 10.3.9.构造器 10.3.10.变量 10.3.10.1.'#this'和'#root'变量 10.3.11.三元操作符(If-Then-Else) 10.3.12.列表的投影(Projection)和选择(Selection) 10.3.13. 集合处理器和聚合器 10.3.13.1.Count聚合器 10.3.13.2.Sum聚合器 10.3.13.3.Average聚合器 10.3.13.4.Minimum聚合器 10.3.13.5.Maximum聚合器 10.3.13.6.nonNull处理器 10.3.13.7.distinct处理器 10.3.13.8.sort处理器 10.3.14.引用容器中的对象 10.3.15.Lambda表达式 10.3.16.空目标 10.4.本章使用的示例类型 第十一章. 验证框架 11.1.简介 11.2.用法示例 11.3.验证对象组 11.4.验证对象 11.4.1.条件验证对象 11.4.2.必需性验证对象 11.4.3.正则表达式验证对象 11.4.4.通用验证对象 11.4.5.条件型验证 11.5.验证行为 11.5.1.错误消息行为 11.5.2.通用行为 11.6.引用验证对象 11.7.在ASP.NET中的使用技巧 11.7.1.显示验证错误 11.7.1.1.配置错误显示类 第十二章. 使用Spring.NET进行面向方面的编程 12.1.简介 12.1.1.AOP基本概念 12.1.2.Spring.NET AOP的功能 12.1.3.Spring.NET的AOP代理 12.2.Spring.NET中的切入点 12.2.1.概念 12.2.2.切入点的操作 12.2.3.Spring.NET提供的切入点实现类 12.2.3.1.静态切入点 12.2.3.2.动态切入点 12.2.4.自定义切入点 12.3.Spring.NET的通知类型 12.3.1.通知的生命周期 12.3.2.通知类型 12.3.2.1.拦截环绕通知 12.3.2.2.前置通知 12.3.2.3.异常通知 12.3.2.4.后置通知 12.3.2.5.引入通知 12.4.Spring.NET中的Advisor 12.5.使用ProxyFactoryObject创建AOP代理 12.5.1.基本原理 12.5.2.ProxyFactoryObject的属性 12.5.3.代理接口 12.5.4.代理一个类 12.6.使用ProxyFactory类以编程方式创建AOP代理 12.7.管理目标对象 12.8.使用“自动代理”功能 12.8.1.自动代理对象的定义 12.8.1.1.ObjectNameAutoProxyCreator 12.8.1.2.DefaultAdvisorAutoProxyCreator 12.8.1.3.AbstractAutoProxyCreator 12.8.2.使用特性驱动的自动代理 12.9.使用TargetSources 12.9.1.动态切换TargetSource 12.9.2.池化TargetSource 12.9.3.PrototypeTargetSource 12.10.定义新的通知类型 12.11.参考资源 第十三章.通用日志抽象层 13.1.简介 13.1.1.Logging API 13.2.实现与配置 13.2.1.控制台Logger 13.3.Log4Net 第二部分. 中间层数据访问 第十四章. 事务管理 14.1.简介 14.2.动机 14.3.核心接口 14.4.用事务进行资源同步 14.4.1.高层次方法 14.4.2.低层次方法 14.5.声明式事务管理 14.5.1.理解Spring.NET声明式事务管理的实现 14.5.2.第一个例子 14.5.3.Transaction特性的设置 14.5.4.通过AutoProxyCreator使用声明式事务 14.5.5.通过TransactionProxyFactoryObject使用声明式事务 14.5.6. 通过ProxyFactoryObject使用声明式事务 14.5.7. Using Abstract object definitions 14.5.8. Declarative Transactions using ProxyFactoryObject 14.6. 编程方式的事务管理 14.6.1.使用TransactionTemplate 14.6.2.使用IPlatformTransactionManager 14.7.选择编程方式还是声明方式 第十五章. 数据访问对象 15.1.简介 15.2.统一的异常体系 15.3.为数据访问对象提供的统一抽象基类 第十六章. DbProvider 16.1.简介 16.1.1.IDbProvider和DbProviderFactory 16.1.2. XML配置 16.1.3.管理连接字符串 第十七章. 使用ADO.NET进行数据访问 17.1.简介 17.2.动机 17.3.Provider抽象 17.3.1.创建IDbProvider类型的实例 17.4.命名空间 17.5.数据访问的方式 17.6.AdoTemplate简介 17.6.1.执行回调 17.6.2.在.NET 2.0中执行回调 17.6.3. .NET 1.1 17.6.4.AdoTemplate方法指南 17.7.异常翻译 17.8.参数管理 17.8.1. IDbParametersBuilder 17.8.2. IDbParameters 17.9. Mapping DBNull values 17.10. Basic data access operations 17.10.1. ExecuteNonQuery 17.10.2. ExecuteScalar 17.11. Queries and Lightweight Object Mapping 17.11.1. ResultSetExtractor 17.11.2. RowCallback 17.11.3. RowMapper 17.11.4. Query for a single object 17.11.5. Query using a CommandCreator 17.12. DataTable and DataSet 17.12.1. DataTables 17.12.2. DataSets 17.13. Deriving Stored Procedure Parameters 17.14. Database operations as Objects 17.14.1. AdoNonQuery 17.14.2. AdoQuery 17.14.3. MappingAdoQuery 17.14.4. Stored Procedure 17.14.5. DataSetOperation 18. ORM集成 18.1. 简介 第三部分. Web框架 第十九章. Web框架 19.1.简介 19.2.自动装载应用程序上下文和应用程序上下文嵌套 19.2.1. 配置 19.2.2.上下文嵌套 19.3.为ASP.NET页面进行依赖注入 19.3.1.为Web控件进行依赖注入 19.4.Master Page 19.4.1.将子页面与Master Page关联 19.5.双向数据绑定 19.5.1.数据绑定的后台实现 19.5.1.1.绑定方向 19.5.1.2.Formatters 19.5.1.3.类型转换 19.5.1.4.数据绑定事件 19.6.本地化 19.6.1.使用Localizer进行自动本地化(“推”模型) 19.6.2.使用Localizer 19.6.3.手动应用资源(“拉”模型的本地化) 19.6.4.在Web应用程序中进行图像本地化 19.6.5.全局资源 19.6.6.用户语言文化管理 19.6.6.1. DefaultWebCultureResolver 19.6.6.2. RequestCultureResolver 19.6.6.3. SessionCultureResolver 19.6.6.4. CookieCultureResolver 19.6.7.更改语言文化 19.7.结果映射 19.8.客户端脚本 19.8.1.在HTML的head节点内注册客户端脚本 19.8.2.向节点中添加CSS定义 19.8.3.全局目录(Well-Known Directories) 第四部分. 服务 第二十章. .NET Remoting 20.1.简介 20.2.在服务端发布SAO 20.2.1.SAO Singleton 20.2.2.SAO SingleCall 20.2.3.IIS应用程序配置 20.3.在客户端访问SAO 20.4.CAO 最佳实践 20.5.在服务端注册CAO 20.5.1.向CAO对象应用AOP通知 20.6.在客户端访问CAO 20.6.1.向客户端的CAO对象应用AOP通知 20.7. XML Schema for configuration 20.8.参考资源 第二十一章. .NET企业服务 21.1.简介 21.2.服务组件 21.3.服务端 21.4.客户端 第二十二章. Web服务 22.1.服务端 22.1.1.消除对.asmx文件的依赖 22.1.2.向web服务中注入依赖项 22.1.3.将PONO发布为web服务 22.1.4.将AOP代理发布为web服务 22.1.5.客户端的问题 22.2.客户端 22.2.1.WebServiceProxyFactory 22.2.2.WebServiceClientFactory 第二十三章. Windows后台服务 23.1.备注 23.2.简介 23.3.Spring.Services.WindowsService.Process.exe应用程序 23.3.1.安装 23.3.2.配置 23.4.将应用程序上下文发布为Windows服务 23.4.1.service.config 23.4.1.1.让应用程序了解自身的位置 23.4.2.watcher.xml - 可选的配置 23.4.3.bin目录 - 可选 23.5.自定义或扩展 23.5.1. .config文件 第五部分. 与Visual Studio.NET集成 第二十四章. 与Visual Studio.NET集成 24.1.XML编辑与验证 24.2.XML Schema的版本 24.3.集成API文档 第六部分. 快速入门程序 第二十五章. IoC快速入门 25.1.简介 25.2.Movie Finder 25.2.1.开始建立MovieFinder应用程序 25.2.2.第一个对象定义 25.2.3.属性注入 25.2.4.构造器参数注入 25.2.5.总结 25.2.6.日志 25.3.应用程序上下文和IMessageSource接口 25.3.1.简介 25.4.应用程序上下文和IEventRegistry接口 25.4.1.简介 25.5.对象池示例 25.5.1.实现Spring.Pool.IPoolableObjectFactory 25.5.2.使用池中的对象 25.5.3.利用executor执行并行的grep 25.6.AOP 第二十六章. AOP指南 26.1.简介 26.2.基础知识 26.2.1.应用通知 26.2.2.使用切入点-基本概念 26.3.深入探讨 26.3.1.其它类型的通知 26.3.1.1.前置通知 26.3.1.2.后置通知 26.3.1.3.异常通知 26.3.1.4.引入(mixins) 26.3.1.5.通知链 26.3.1.6.配置通知 26.3.2.使用特性定义切入点 26.4.The Spring.NET AOP Cookbook 26.4.1.缓存 26.4.2.性能监视 26.4.3.重试规则 Spring.NET AOP最佳实践 第二十七章. .NET Remoting快速入门 27.1.简介 27.2.Remoting实例程序 27.3.实现 27.4.运行程序 27.5.Remoting Schema 27.6.参考资源 第二十八章. Web框架快速入门 28.1.简介 第二十九章. SpringAir - 参考程序 29.1.简介 29.2.架构 29.3.实现 29.3.1.业务层 29.3.2.服务层 29.3.3.Web层 29.4.总结 第三十章. 数据访问快速入门 30.1.简介 第三十一章. 事务管理快速入门 31.1.简介 31.2.应用程序概述 31.2.1.接口 第七部分. Java开发人员必读 第三十二章. Java开发人员必读 32.1.简介 32.2.Beans和Objects 32.3.PropertyEditor和TypeConverter 32.4.ResourceBundle和ResourceManager 32.5.异常 32.6.应用程序配置 32.7.AOP框架
课程通过实际项目融入常用开发技术架构,讲授风格独特,提供详细上课日志及答疑,赠送配套的项目架构源码注释详细清晰且表达通俗,均能直接在实际项目中应用,正真的物超所值,价格实惠任务作业:综合运用《C#/.Net企业级系统架构设计实战精讲教程》课程所学知识技能设计一个学生成绩管理系统的架构。要求:1.系统基于MVC的三层架构,各层单独建不同的解决方案文件夹。2.采用Model First开发方式,设计架构时只需要设计学生表(TbStudent)和课程表(TbCourse)。学生表必须有的字段是ID、stuName、age;课程表必须有的字段是ID、courseName、content。3.数据访问层采用Entity Framework或NHibernate来实现,必须封装对上述表的增删改查方法。4.必须依赖接口编程,也就是必须要有数据访问层的接口层、业务逻辑层的接口层等接口层。层层之间必须减少依赖,可以通过简单工厂或抽象工厂。5.至少采用简单工厂、抽象工厂、Spring.Net等技术中的2种来减少层与层之间的依赖等。6.封装出DbSession类,让它拥有所有Dal层实例和SaveChanges方法。7.设计出数据访问层及业务逻辑层主要类的T4模板,以便实体增加时自动生成相应的类。8.表现层要设计相关的控制器和视图来验证设计的系统架构代码的正确性,必须含有验证增删改查的方法。9.开发平台一定要是Visual Studio平台,采用C#开发语言,数据库为SQL Server。10.提交整个系统架构的源文件及生成的数据库文件。(注意: 作业需写在CSDN博客中,请把作业链接贴在评论区,老师会定期逐个批改~~)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值