Spring 框架简介外文翻译
xxxx大学xxx学院
毕业设计（论文）外文文献翻译
系部xxxx
专业xxxx
学生姓名xxxx 学号xxxx
指导教师xxxx 职称xxxx
2013年3 月
Introducing the Spring Framework
The Spring Framework: a popular open source application framework that addresses many of the issues outlined in this book. This chapter will introduce the basic ideas of Spring and dis-cuss the central “bean factory” lightweight Inversion-of-Control (IoC) container in detail.
Spring makes it particularly easy to implement lightweight, yet extensible, J2EE archi-tectures. It provides an out-of-the-box implementation of the fundamental architectural building blocks we recommend. Spring provides a consistent way of structuring your applications, and provides numerous middle tier features that can make J2EE development significantly easier and more flexible than in traditional approaches.
The basic motivations for Spring are:
To address areas not well served by other frameworks. There are numerous good solutions to specific areas of J2EE infrastructure: web frameworks, persistence solutions, remoting tools, and so on. However, integrating these tools into a comprehensive architecture can involve significant effort, and can become a burden. Spring aims to provide an end-to-end solution, integrating spe-cialized frameworks into a coherent overall infrastructure. Spring also addresses some areas that other frameworks don’t. For example, few frameworks address generic transaction management, data access object implementation, and gluing all those things together into an application, while still allowing for best-of-breed choice in each area. Hence we term Spring an application framework, rather than a web framework, IoC or AOP framework, or even middle tier framework.
To allow for easy adoption. A framework should be cleanly layered, allowing the use of indi-vidual features without imposing a whole world
view on the application. Many Spring features, such as the JDBC abstraction layer or Hibernate integration, can be used in a library style or as part of the Spring end-to-end solution.
To deliver ease of use. As we’ve noted, J2EE out of the box is relatively hard to use to solve many common problems. A good infrastructure framework should make simple tasks simple to achieve, without forcing tradeoffs for future complex requirements (like distributed transactions) on the application developer. It should allow developers to leverage J2EE services such as JTA where appropriate, but to avoid dependence on them in cases when they are unnecessarily complex.
To make it easier to apply best practices. Spring aims to reduce the cost of adhering to best practices such as programming to interfaces, rather than classes, almost to zero. However, it leaves the choice of architectural style to the developer.
Non-invasiveness. Application objects should have minimal dependence on the framework. If leveraging a specific Spring feature, an object should depend only on that particular feature, whether by implementing a callback interface or using the framework as a class library. IoC and AOP are the key enabling technologies for avoiding framework dependence.
Consistent configuration. A good infrastructure framework should keep application configuration flexible and consistent, avoiding the need for custom singletons and factories. A single style should be applicable to all configuration needs, from the middle tier to web controllers.
Ease of testing. Testing either whole applications or individual application classes in unit tests should be as easy as possible. Replacing resources or application objects with mock objects should be straightforward.
To allow for extensibility. Because Spring is itself based on interfaces, rather than classes, it is easy to extend or customize it. Many Spring components use strategy interfaces, allowing easy customization.
A Layered Application Framework
Chapter 6 introduced the Spring Framework as a lightweight container, competing with IoC containers such as PicoContainer. While the Spring lightweight container for JavaBeans is a core concept, this is just the foundation for a solution for all middleware layers.
Basic Building Blocks
pring is a full-featured application framework that can be leveraged at many levels. It consists of multi-ple sub-frameworks that are fairly independent but still integrate closely into a one-stop shop, if desired. The key areas are:
Bean factory. The Spring lightweight IoC container, capable of configuring and wiring up Java-Beans and most plain Java objects, removing the need for custom singletons and ad hoc configura-tion. Various out-of-the-box implementations include an XML-based bean factory. The lightweight IoC container and its Dependency Injection capabilities will be the main focus of this chapter.
Application context. A Spring application context extends the bean factory concept by adding support for message sources and resource loading, and providing hooks into existing environ-ments. Various out-of-the-box implementations include standalone application contexts and an XML-based web application context.
AOP framework. The Spring AOP framework provides AOP support for method interception on any class managed by a Spring lightweight container.
It supports easy proxying of beans in a bean factory, seamlessly weaving in interceptors and other advice at runtime. Chapter 8 dis-cusses the Spring AOP framework in detail. The main use of the Spring AOP framework is to provide declarative enterprise services for POJOs.
Auto-proxying. Spring provides a higher level of abstraction over the AOP framework and low-level services, which offers similar ease-of-use to .NET within a J2EE context. In particular, the provision of declarative enterprise services can be driven by source-level metadata.
Transaction management. Spring provides a generic transaction management infrastructure, with pluggable transaction strategies (such as JTA and JDBC) and various means for demarcat-ing transactions in applications. Chapter 9 discusses its rationale and the power and flexibility that it offers.
DAO abstraction. Spring defines a set of generic data access exceptions that can be used for cre-ating generic DAO interfaces that throw meaningful exceptions independent of the underlying persistence mechanism. Chapter 10 illustrates the Spring support for DAOs in more detail, examining JDBC, JDO, and Hibernate as implementation strategies.
JDBC support. Spring offers two levels of JDBC abstraction that significantly ease the effort of writing JDBC-based DAOs: the org.springframework.jdbc.core package (a template/
callback approach) and the org.springframework.jdbc.object package (modeling RDBMS operations as reusable objects). Using the Spring JDBC packages can deliver much greater pro-ductivity and eliminate the potential for common errors such as leaked connections, compared with direct use of JDBC. The Spring JDBC abstraction integrates with the transaction and DAO abstractions.
Integration with O/R mapping tools. Spring provides support classes
for O/R Mapping tools like Hibernate, JDO, and iBATIS Database Layer to simplify resource setup, acquisition, and release, and to integrate with the overall transaction and DAO abstractions. These integration packages allow applications to dispense with custom ThreadLocal sessions and native transac-tion handling, regardless of the underlying O/R mapping approach they work with.
Web MVC framework. Spring provides a clean implementation of web MVC, consistent with the JavaBean configuration approach. The Spring web framework enables web controllers to be configured within an IoC container, eliminating the need to write any custom code to access business layer services. It provides a generic DispatcherServlet and out-of-the-box controller classes for command and form handling. Request-to-controller mapping, view resolution, locale resolution and other important services are all pluggable, making the framework highly extensi-ble. The web framework is designed to work not only with JSP, but with any view technology, such as Velocity—without the need for additional bridges. Chapter 13 discusses web tier design and the Spring web MVC framework in detail.
Remoting support. Spring provides a thin abstraction layer for accessing remote services without hard-coded lookups, and for exposing Spring-managed application beans as remote services. Out-of-the-box support is inc luded for RMI, Caucho’s Hessian and Burlap web service protocols, and WSDL Web Services via JAX-RPC. Chapter 11 discusses lightweight remoting.
While Spring addresses areas as diverse as transaction management and web MVC, it uses a consistent approach everywhere. Once you have learned the basic configuration style, you will be able to apply it in many areas. Resources, middle tier objects, and web components are all set up using the same bean configuration mechanism. You can combine your entire
configuration in one single bean definition file or split it by application modules or layers; the choice is up to you as the application developer. There is no need for diverse configuration files in a variety of formats, spread out across the application.
Spring on J2EE
Although many parts of Spring can be used in any kind of Java environment, it is primarily a J2EE application framework. For example, there are convenience classes for linking JNDI resources into a bean factory, such as JDBC DataSources and EJBs, and integration with JTA for distributed transaction management. In most cases, application objects do not need to work with J2EE APIs directly, improving reusability and meaning that there is no need to write verbose, hard-to-test, JNDI lookups.
Thus Spring allows application code to seamlessly integrate into a J2EE environment without being unnecessarily tied to it. You can build upon J2EE services where it makes sense for your application, and choose lighter-weight solutions if there are no complex requirements. For example, you need to use JTA as transaction strategy only if you face distributed transaction requirements. For a single database, there are alternative strategies that do not depend on a J2EE container. Switching between those transac-tion strategies is merely a matter of configuration; Spring’s consistent abstraction avoids any need to change application code.
Spring offers support for accessing EJBs. This is an important feature (and relevant even in a book on “J2EE without EJB”) because the u se of dynamic proxies as codeless client-side business delegates means that Spring can make using a local stateless session EJB an implementation-level, rather than a fundamen-tal architectural, choice.
Thus if you want to use EJB, you can within a consistent architecture; however, you do not need to make EJB the cornerstone of your architecture. This Spring feature can make devel-oping EJB applications significantly faster, because there is no need to write custom code in service loca-tors or business delegates. Testing EJB client code is also much easier, because it only depends on the EJB’s Business Methods interface (which is not EJB-specific), not on JNDI or the EJB API.
Spring also provides support for implementing EJBs, in the form of convenience superclasses for EJB implementation classes, which load a Spring lightweight container based on an environment variable specified in the ejb-jar.xml deployment descriptor. This is a powerful and convenient way of imple-menting SLSBs or MDBs that are facades for fine-grained POJOs: a best practice if you do choose to implement an EJB application. Using this Spring feature does not conflict with EJB in any way—it merely simplifies following good practice.
Introducing the Spring Framework
The main aim of Spring is to make J2EE easier to use and promote good programming practice. It does not reinvent the wheel; thus you’ll find no logging packages in Spring, no connection pools, no distributed transaction coordinator. All these features are provided by other open source projects—such as Jakarta Commons Logging (which Spring uses for all its log output), Jakarta Commons DBCP (which can be used as local DataSource), and ObjectWeb JOTM (which can be used as transaction manager)—or by your J2EE application server. For the same reason, Spring doesn’t provide an O/R mapping layer: There are good solutions for this problem area, such as Hibernate and JDO.
Spring does aim to make existing technologies easier to use. For example, although Spring is not in the business of low-level transaction
coordination, it does provide an abstraction layer over JTA or any other transaction strategy. Spring is also popular as middle tier infrastructure for Hibernate, because it provides solutions to many common issues like SessionFactory setup, ThreadLocal sessions, and exception handling. With the Spring HibernateTemplate class, implementation methods of Hibernate DAOs can be reduced to one-liners while properly participating in transactions.
The Spring Framework does not aim to replace J2EE middle tier services as a whole. It is an application framework that makes accessing low-level J2EE container ser-vices easier. Furthermore, it offers lightweight alternatives for certain J2EE services in some scenarios, such as a JDBC-based transaction strategy instead of JTA when just working with a single database. Essentially, Spring enables you to write appli-cations that scale down as well as up.
Spring for Web Applications
A typical usage of Spring in a J2EE environment is to serve as backbone for the logical middle tier of a J2EE web application. Spring provides a web application context concept, a powerful lightweight IoC container that seamlessly adapts to a web environment: It can be accessed from any kind of web tier, whether Struts, WebWork, Tapestry, JSF, Spring web MVC, or a custom solution.
The following code shows a typical example of such a web application context. In a typical Spring web app, an applicationContext.xml file will reside in the WEB-INF directory, containing bean defini-tions according to the “spring-beans” DTD. In such a bean definition XML file, business objects and resources are defined, for example, a “myDataSource” bean, a “myInventoryManager” bean, and a “myProductManager” bean. Spring takes care of their configuration, their wiring up, and their lifecycle.
Driver
By default, all such beans have “singleton” scope: one instance per context. The “myInventoryManager” bean will automatically be wired up with the defined DataSource, while “myProductManager” will in turn receive a reference to the “myInventoryManager” bean. Those objects (traditionally called “beans” in Spring terminology) need to expos e only the corresponding bean properties or constructor arguments (as you’ll see later in this chapter); they do not have to perform any custom lookups.
A root web application context will be loaded by a ContextLoaderListener that is defined in web.xml as follows:
org.springframework.web.context.ContextLoaderListener
...
After initialization of the web app, the root web application context will be available as a ServletContext attribute to the whole web application, in the usual manner. It can be retrieved from there easily via fetching the corresponding attribute, or via a convenience method in org.springframework.web. context.support.WebApplicationContextUtils. This means that the application context will be available in any web resource with access to the ServletContext, like a Servlet, Filter, JSP, or Struts Action, as follows:
WebApplicationContext wac = WebApplicationContextUtils.
getWebApplicationContext(servletContext);
The Spring web MVC framework allows web controllers to be defined as JavaBeans in child application contexts, one per dispatcher servlet. Such controllers can express dependencies on beans in the root application context via simple bean references. Therefore, typical Spring web MVC applications never need to perform a manual lookup of an application context or bean factory, or do any other form of lookup.
Neither do other client objects that are managed by an application context themselves: They can receive collaborating objects as bean references.
The Core Bean Factory
In the previous section, we have seen a typical usage of the Spring IoC container in a web environment: The provided convenience classes allow for seamless integration without having to worry about low-level container details. Nevertheless, it does help to look at the inner workings to understand how Spring manages the container. Therefore, we will now look at the Spring bean container in more detail, starting at the lowest building block: the bean factory. Later, we’ll continue with resource setup and details on the application context concept.
One of the main incentives for a lightweight container is to dispense with the multitude of custom facto-ries and singletons often found in J2EE applications. The Spring bean factory provides one consistent way to set up any number of application objects, whether coarse-grained components or fine-grained busi-ness objects. Applying reflection and Dependency Injection, the bean factory can host components that do not need to be aware of Spring at all. Hence we call Spring a non-invasive application framework.
Fundamental Interfaces
The fundamental lightweight container interface is org.springframework.beans.factory.Bean Factory. This is a simple interface, which is easy to implement directly in the unlikely case that none of the implementations provided with Spring suffices. The BeanFactory interface offers two getBean() methods for looking up bean instances by String name, with the option to check for a required type (and throw an exception if there is a type mismatch).
public interface BeanFactory {
Object getBean(String name) throws BeansException;
Object getBean(String name, Class requiredType) throws BeansException;
boolean containsBean(String name);
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
String[] getAliases(String name) throws NoSuchBeanDefinitionException;
}
The isSingleton() method allows calling code to check whether the specified name represents a sin-gleton or prototype bean definition. In the case of a singleton bean, all calls to the getBean() method will return the same object instance. In the case of a prototype bean, each call to getBean() returns an inde-pendent object instance, configured identically.
The getAliases() method will return alias names defined for the given bean name, if any. This mecha-nism is used to provide more descriptive alternative names for beans than are permitted in certain bean factory storage representations, such as XML id attributes.
The methods in most BeanFactory implementations are aware of a hierarchy that the implementation may be part of. If a bean is not found
in the current factory, the parent factory will be asked, up until the root factory. From the point of view of a caller, all factories in such a hierarchy will appear to be merged into one. Bean definitions in ancestor contexts are visible to descendant contexts, but not the reverse.
All exceptions thrown by the BeanFactory interface and sub-interfaces extend org.springframework. beans.BeansException, and are unchecked. This reflects the fact that low-level configuration prob-lems are not usually recoverable: Hence, application developers can choose to write code to recover from such failures if they wish to, but should not be forced to write code in the majority of cases where config-uration failure is fatal.
Most implementations of the BeanFactory interface do not merely provide a registry of objects by name; they provide rich support for configuring those objects using IoC. For example, they manage dependen-cies between managed objects, as well as simple properties. In the next section, we’ll look at how such configuration can be expressed in a simple and intuitive XML structure.
The sub-interface org.springframework.beans.factory.ListableBeanFactory supports listing beans in a factory. It provides methods to retrieve the number of beans defined, the names of all beans, and the names of beans that are instances of a given type:
public interface ListableBeanFactory extends BeanFactory {
int getBeanDefinitionCount();
String[] getBeanDefinitionNames();
String[] getBeanDefinitionNames(Class type);
boolean containsBeanDefinition(String name);
Map getBeansOfType(Class type, boolean includePrototypes,
boolean includeFactoryBeans) throws BeansException
}
The ability to obtain such information about the objects managed by a ListableBeanFactory can be used to implement objects that work with a set of other objects known only at runtime.
In contrast to the BeanFactory interface, the methods in ListableBeanFactory apply to the current factory instance and do not take account of a hierarchy that the factory may be part of. The org.spring framework.beans.factory.BeanFactoryUtils class provides analogous methods that traverse an entire factory hierarchy.
There are various ways to leverage a Spring bean factory, ranging from simple bean configuration to J2EE resource integration and AOP proxy generation. The bean factory is the central, consistent way of setting up any kind of application objects in Spring, whether DAOs, business objects, or web controllers. Note that application objects seldom need to work with the BeanFactory interface directly, but are usu-ally configured and wired by a factory without the need for any Spring-specific code.
For standalone usage, the Spring distribution provides a tiny spring-core.jar file that can be embed-ded in any kind of application. Its only third-party dependency beyond J2SE 1.3 (plus JAXP for XML parsing) is the Jakarta Commons Logging API.
The bean factory is the core of Spring and the foundation for many other services that the framework offers. Nevertheless, the bean factory can easily be used stan-dalone if no other Spring services are required.
Derivative：network
Spring 框架简介
Spring框架：这是一个流行的开源应用框架，它可以解决很多问题。这里主要介绍Spring的基本概念，并详细介绍其中以“bean工厂”为核心的轻量级控制反转（IoC）容器。
Spring让开发者更轻松的实现轻量级、可扩展的J2EE架构。对于我们推荐的架构模块，让Spring提供了即时可用的实现。此外，Spring还提供了同意的应用架构方式，以及大量的中间层功能模块，能大大简化了J2EE的开发，并且比传统的开发方式更加灵活。
第一章：Spring项目的出发点
1.1解决被其它框架忽略的部分
在J2EE的各个具体领域都有很多出色的解决方案----web框架、持久化方案、远程调用工具，凡此种种。然而，将这些工具整合成一个全面的架构却困难重重，甚至成为一种负担。Spring的目标就是提供一种贯穿始终的解决方案，将各种专用框架整合成一个连贯的整体架构。Spring还涉及到其它框架没有触及到的地方。例如，很少有框架提供普遍适用的事务管理或是数据库存储对象实现；即便各个领域都有很好的选择，也没有一个框架能够帮忙把所有这些东西整合到一个应用中去。因此，我们说Spring是一个应用框架，而不是web框架、IoC框架、AOP框架或者中间层框架什么的。
1.2易于选择
一个框架应该有清楚的层次划分，允许用户使用其中的单项功能，而不是把自己的整个世界观强加给用户。Spring中的许多特性---例如JDBC抽象层或者Hibernation集成----都可以作为一个库单独使用，当然也可以作为Spring整体方案的一个部分。
1.3易于使用
正如前面说过的，仅仅J2EE本身并不易用---很多常见的问题光靠J2EE都很难解决。一个好的基础框架首先应该让容易的任务容易完成，而不需要让应用开发人员现在就为将来的复杂需求（例如分布式事务）买单。框架应该帮助开发
人员合理使用J2EE的服务（例如JTA），同时又避免造成对服务的依赖，从而减少不必要的复杂性。
1.4 鼓励最佳实现
Spring力求把遵循最佳实践--例如“针对接口编程”--的成本降低到最小。另一方面，Spring又力求不强加任何架构风格，而是把选择的权利留给开发者。
1.5 非入侵性
一个好的基础设施框架应保持应用组态灵活和一致，避免自定义单身和工厂的需要。一个单一的风格应该是适用于所有配置的需要，从中间层的网络控制器。
1.6 统一配置
测试整个应用程序或单个应用程序类的单元测试应该尽可能的容易。模仿对象替换资源或应用程序的对象应该是简单的。
1.7 可扩展
由于Spring本身是基于接口的，而不是类，它是很容易扩展或定制。许多Spring组件使某种形式的Strategy模式，因此可以方便定制。
第二章：一个分层的应用框架
前面我们从轻量级容器（lightwight container）的角度介绍了Spring框架，并将其与别的IoC容器（例如PicoContainer) 作了比较。虽然为JavaBean 设计的轻量级容器是Spring的核心概念，但这也只是所有中间层解决方案的基础而已。
2.1 基础构建模块
Spring是一个完整的应用框架，它可以在很懂应用层发挥作用。Spring由多个子框架组成，而且这些框架都是相对独立的。不过，只要你愿意，你就可以将它们无缝集成起来，成为一个全面的应用框架，下面讲解Spring框架的关键概念。
2.1.1 bean工厂
Spring轻量级IoC容器能够配置、装备JavaBean和大多数Java对象，使得开发者不必定制Singleton和自己的配置机制。Spring提供了多个“即拿即用”的bean工厂实现。其中包括一个基于XML的bean工厂。轻量级IoC容器和
依赖注入（Dependency Injcction）将是本章节关注的内容。
2.1.2应用上下文
Spring应用程序上下文添加消息来源和资源加载支持扩展bean工厂的概念，并提供钩到现有的环境中。不同的盒子的实现包括独立的应用程序上下文和基于Web的应用程序上下文的XML。
2.1.3 AOP框架
Spring的AOP框架提供的任何类的Spring轻量级容器管理方法拦截AOP支持。可以对轻量级容器管理的任何对象进行方法拦截。在bean工厂中，可以轻松的为JavaBean提供代理，从而在运行天衣无缝地将拦截器和其他的adcice 整合进来。我们将在后面详细讨论Spring的AOP框架。Spring AOP的主要用途就是为了POJO提供声明性的企业级服务。
2.1.4 自动代理
Spring提供了一个更高的抽象层次的AOP框架和低水平的服务，同时也提供了很多基础性的服务，从而在J2EE环境中提供了类似于.NET的易用性--特别是，声明的企业提供的服务可以通过源代码级的元数据驱动的。
2.1.5 事务管理
Spring提供了一个通用的交易管理基础设施，可插拔的交易策略（例如JTA 和JDBC）和不同的事务划分方式。后面会详细介绍Spring事务管理的基本原理，及其强大的威力和灵活性。
2.1.6 DAO的抽象
Spring定义一组通用的数据访问异常，在创建通用的DAO接口时可以用这些异常类型抛出有意义的异常信息，，独立于底层的存储机制。后面阐述了更多的细节讨论Spring对DAO的支持，以及针对JDBC JDO，Hibernate的不同实施策略。
2.1.7 JDBC的支持
Spring提供了两个层次的抽象，使得编写基于JDBC的DAO特别简单：org.springframework.jdbc.core包提供了基于模板、回调的JDBC用法，org.springframework.jdbc.object包则把关系数据库操作建模为可服用对象。比起直接使用JDBC，用Spring 的JDBC包可以提供更大的生产力和消除常见的错误，如泄漏等。Spring JDBC抽象层集成了事务抽象和DAO的抽象。
2.1.8 集成O/R映工具
Spring提供了多种O/R映射工具的支持，如Hibernate，JDO和ibatis数据库简化资源设置，采集，和释放，并且将O/R映射与整个事务和DAO抽象集成起来。这些集成软件包允许应用程序分配自定义ThreadLocal会话和本地事务进行处理，不必考虑底层究竟采用哪种O/R映射工具。
2.1.9 web MVC框架
Spring提供了一个相当干净的Web MVC实现--同样使用了统一JavaBean配置方式。使用Spring web框架时，web控制器也可以在IoC容器中配置，从而不必为“访问业务层服务”额外编写代码。Spring还提供了通用的DispatcherServlet和“即拿急用”的控制器类。请求与控制器之间的映射方式、师徒的判断、本地化、以及其他重要服务都是可以插的，使得整个框架酷友更好的扩展性。Spring web框架设计不仅仅局限于JSP，还可以与其他的视图技术--例如Velocity--无缝的结合。
2.1.10 远程调用支持
Spring提供一种薄的抽象层用于访问远程服务，避免了在应用对象中硬编码对服务的查找。线成支持的远程调用方式包括RMI，Caucho的Hessian和Burlap Web服务的协议，和基于JAX-RPCWSDL的Web服务。
虽然Spring涉及了下至事务管理、上至web MVC的不同领域，它但它解决问题的方式却是一以贯之的。一旦你学会了基本的配置方式，你将能够应用在许多领域。资源，中间层对象，和Web组件都使用同一个bean配置机制的建立。你可以将你的整个配置在一个单一的bean定义文件或分裂，它的应用模块或层；选择是为应用程序开发人员到你。有没有需要在各种不同的格式，不同的配置文件，遍布的应用。
第三章：J2EE之上的Spring
虽然Spring的许多部分可用于任何Java环境，它主要是一个J2EE应用框架。例如，有链接到一个bean工厂的JNDI资源方便的类，如JDBC数据源和EJB 和JTA，分布式事务管理一体化。在大多数情况下，应用程序对象不需要与j2ee api直接，提高可重用性和意义，不需要写冗长，难以测试，JNDI查找。
因此，Spring允许应用程序代码的无缝集成到J2EE环境不被不必要地捆绑在一起。你可以建立在J2EE服务，让您的应用程序，如果没有复杂的要求选择
重量轻的解决方案。例如，你需要使用JTA事务的策略，如果你面对分布式事务的要求。为一个单一的数据库，有不依赖于一个J2EE容器替代策略。这些交易和策略之间的切换只是配置；春天的一致的抽象避免任何需要更改应用程序代码。
Spring访问EJB提供支持。这是一个重要的特征（甚至在“没有EJB的J2EE 一本有关）因为动态使用代理作为客户端业务代表无代码意味着春天可以使用本地的无状态会话EJB的实现程度，而不是一个根本的建筑，选择。因此，如果你想使用EJB，您可以在一个一致的架构；然而，你不需要让你的架构的基石，EJB。今年春天功能可以使开发EJB应用程序更快，因为不需要编写自定义代码在服务中心职责范围或业务代表。测试EJB客户端代码也容易得多，因为它不仅取决于EJB的业务方法接口（这是不特定的，不是在EJB）或EJB JNDI API。
Spring也提供了实现EJB的支持，在方便的超类EJB实现类的形式，其中负载基于ejb-jar.xml部署描述符指定的环境变量的Spring轻量级容器。这是一个强大的和方便的方式实现SLSBs或MDBS是细粒度的POJO立面：最佳实践，如果你选择实现EJB应用。Spring的这些特性和EJB毫无冲突，因为它只是遵循了公认的最佳实践而已。
Spring的主要目的是使J2EE更容易使用和促进良好的编程实践。Spring 不重新发明轮子，这样你会在spring找不到登录包，连接池，分布式事务协调器。这些特征是由其他的开源项目，如Jakarta Commons测井提供（Spring使用其所有的日志输出），Jakarta Commons DBCP（可作为局部数据源）和ObjectWeb JOTM（可作为事务管理器）或通过你的J2EE应用服务器。出于同样的原因，Spring 不提供O/R映射层：有良好的解决问题的方法，如Hibernate，JDO。
Spring的目标是使现有的技术更容易使用。例如，虽然Spring不是低级事务协调业务，它提供了在jta或者任何交易策略的一个抽象层。Spring为Hibernate提供的中间层的基础设施也很受欢迎，因为它提供了像SessionFactory的设置，许多常见问题可以解决，ThreadLocal会议，与异常处理。与Spring HibernateTemplate类，Hibernate DAO实现方法可以减少到一个衬垫，同时适当参与交易。
Spring框架的目的并不是要取代J2EE中间层服务。这是一个应用程序框架，
信息与计算科学中英文对照外文翻译文献
(文档含英文原文和中文翻译) 中英文对照外文翻译 基于拉格朗日乘数法的框架结构合理线刚度比的研究 【摘要】框架结构是一种常见的多层高层建筑结构；列的合理线刚度比研究是框架结构优化设计中的一个重要方面。本论文研究合理线刚度比时，框架梁、柱的
侧移刚度根据拉格朗日乘数法结构优化的理论和在框架梁、柱的总物质的量一定的前提下，取得最高值。与传统的估计方法和试算梁柱截面尺寸不同，梁、柱的合理的截面尺寸可以在初步设计阶段由派生的公式计算。这种方法不仅作为计算框架梁、柱的截面尺寸基础，确认初步设计阶，而且也被用做类似的结构梁柱合理线刚度比研究的参考。此外，在调整帧梁、柱的截面尺寸的方法的基础上，降低柱的轴向的压缩比，从而达到剪切压缩比和提高结构的延展性。 【关键词】拉格朗日数乘法框架结构刚度比截面尺寸 1 引言 在混凝土框架结构初步设计的期间，通常，框架梁截面高度通过跨度来估算，和截面宽度根据高宽比估算; 框架柱的截面尺寸是根据柱轴压缩的支持柱的面积的比率估算[1]。然而，在估计过程中，初步设计阶段中的一个重要的链，未考虑到柱侧移刚度的影响[2]。列侧移刚度越大，结构层间位的刚度越大，剪切型框架结构的层间位移将越较小。所以，总结构越小的侧向位移将减少地震灾害[3] 所造成的损失。论文的核心是如何得到列侧移刚度的最大值。 同时，列侧移刚度的值与框架梁-柱线刚度直接相关。本论文的目的是为了得到一个合理的框架梁 - 柱的线刚度比，在某个控制范围内获得列侧移刚度的最大值。 计算列横向位移的方法有两种方法：刚度拐点点法和修改拐点法。拐点的方法假定关节的旋转角度为0（当梁柱线性刚度比是大于或等于3时，柱的上端和下端的关节的旋转角度可以取为0，因为它实际上是相当小），即梁的弯曲刚性被视为无穷大。拐点的方法主要是应用于具有比较少层的框架结构。但对于多层、高层框架结构，增加柱截面会导致梁柱线刚度比小于3，在水平荷载作用下，框架结构的所有关节的旋转角度的横向位移会发生不可忽视。因此，一位日本教授武藤提出修改拐点法[4]，即D-值方法。本文采用D-值列侧移刚度的计算法，因为它着重于多层、高层框架结构。 少数在国内外对框架梁柱合理线刚度比的研究，只有梁七黹，源于列侧移刚度的计算方法，比D-值法更加应用广泛；申得氏指出在多层、高层框架结构的柱侧向刚度计算中存在的问题，补充和修改底部和顶部层的列侧向刚度计算公式;
建筑结构设计中英文对照外文翻译文献
中英文对照外文翻译 (文档含英文原文和中文翻译) Create and comprehensive technology in the structure global design of the building The 21st century will be the era that many kinds of disciplines technology coexists , it will form the enormous motive force of promoting the development of building , the building is more and more important too in global design, the architect must seize the opportunity , give full play to the architect's leading role, preside over every building engineering design well. Building there is the global design concept not new of architectural design,characteristic of it for in an all-round way each element not correlated with building- there aren't external environment condition, building , technical equipment,etc. work in coordination with, and create the premium building with the comprehensive new technology to combine together. The premium building is created, must consider sustainable development , namely future requirement , in other words, how save natural resources as much as possible, how about protect the environment that the mankind depends on for existence, how construct through high-quality between architectural design and building, in order to reduce building equipment use quantity and
翻译本质及译学方法专题研讨会记要
“翻译本质及译学方法专题研讨会”记要 由教育部人文社会科学重点研究基地俄语语言文学研究中心、中国译协翻译理论与翻译教学委员会、中国俄语教学研究会、黑龙江大学俄语学院联合主办的“翻译本质及译学方法专题研讨会”，于2008年12月19—22日在北国冰城哈尔滨隆重召开。中国译协发来贺辞，中国俄语教学研究会负责人杜桂枝莅临大会并发表讲话，黑龙江大学校长张政文致欢迎辞。来自高等院校、科研院所等35家单位的52名专家学者齐聚黑龙江大学，另有20余人列席会议。与会代表共提交48篇论文，其中36人做了精彩的大会发言。会议期间还举行了两次学术沙龙，围绕翻译本质问题是否应该悬置、翻译方法与译学方法之别、语料库与翻译、发掘传统与引进西方、纯理思考与注重现实、变译与全译之分等问题展开了讨论。大会安排井然有序，内容丰富，讨论热烈，针对性强，基本达到了会议预期的目的，给与会代表留下了深刻印象。综合所提交论文与大会发言以及沙龙互动的内容，讨论要点可归结为以下三大方面： 1.翻译本质多视角研究 在翻译学学科建设日益迫切的今天，翻译本质问题是其根本性的问题，任何一个研究者不论自觉与否都会考虑这个问题，对其明确与否，了解得全面与否，都会无形中影响其翻译研究，决定其研究选题的取舍。从与会文章来看，这一问题得到了较多的关注。提交的会议48篇论文中有23篇从各自的立场多视角地考察了翻译的本质问题，如从语思统一角度考量翻译本质（高金岭）；取文学翻译视角考察翻译本质（焦鹏帅）；从双语词典翻译考察翻译本质（陈伟）；从可译性角度论及韵体译诗之可行性（郦青）、从翻译模式论及翻译本质（刘泽权、张丽）。学者们认为：建国前中国翻译具有民族性和异质性（贾洪伟）；翻译是多元的（陆永昌）；“译即易，谓换易言语使相解也”，一字可以穷尽译理（罗新璋）；翻译具有历史性，由此可以反思翻译的对等论、相似论以及重译等诸多问题（庞秀成）；翻译是一种语言审美实践（武锐）；翻译属于第二级传播（肖胜文）；“化”是全译的本质（余承法、万光荣）；文学翻译的本质是隐喻性语言的转换生成（苏艳）；本雅明的“纯语言”翻译观从另一个方面揭示了翻译的本质（张文英）；视域融合论是翻译的绝对本质属性（张永中、王国平）；译者作为翻译活动的主体在原文与译文间寻求均衡促成了翻译均衡论（周领顺）。 2. 译学方法多学科研究 方法论研究是一门学科成熟的标志，译学方法论的建设开始受到关注，说明译学开始走向成熟。走向成熟，并非成熟，而只是起步。 翻译研究的一般方法问题在国内开始受到关注，此次会议有所体现，如当前翻译研究应该赞成什么和反对什么、翻译是忠实还是背叛、翻译研究的范式与视角区别何在等问题，值得三思（张会森）；翻译学研究从相邻学科借用思想与方法越来越多，值得探究（杨晓荣）；全译与变译研究奠定了翻译学的基石（李亚舒）；穆雷从翻译学博士论文写作现实出发阐述了翻译研究方法论的重要性；胡庚申从术语学角度厘清了译事、译技、译见、译论、译学等核心概念。 机器翻译研究和翻译的语料库语言学研究本次会议也成为一个亮点，如基于统计的机器翻译把翻译看成解读密码的过程（冯志伟）；翻译具有再生性，对人译与机译理论建模和工程实践中的学术探索具有理论价值和应用价值（易绵竹）；形式语法的本质是自然语言建模，对机器翻译、信息检索和抽取、自动校对均具重要价值（许汉成）。语料库是时兴的翻译研究手段，越来越多的学者进入这一研究领域，如莎士比亚戏剧英汉平行语料库的创建与应用（胡开宝、邹颂兵）、基于《天演论》变译平行语料库的变译思想研究（黄忠廉）、基于本体的俄汉机器翻译基本句库的设计（姚爱刚）。另外还有学者从文本类型学角度论科技翻译（丛亚平）、从场景—框架语义理论研究文学翻译（邓静）、从对比语义学角度探讨词汇的转换（高兰英）、用关联原则解读幽默讽刺话语的翻译（黄杨英）、从模因的角度看归化与异化的动态统一过程（尹铁超、王娜）、从术语学角度讨论语言学术语的翻译（彭玉海）。 3. 其他议题 与翻译相关的论题还有：赵为“中国武侠小说俄译初探”、张淳“多元文化背景下的中译外教学探讨”、孙翠英“文学翻译中异国情调的传达——情感模式的翻译”、高雅古丽·卡德尔“语篇理论在高校翻译教学中的移植与实践作用”、韩振宇“翻译的社会功能标准”、李利群“俄罗斯文学作品标题翻译技巧”、刘丽芬“俄语标题结构汉译模式”、阎萍“商贸日语文章中的翻译问题”。 78
框架结构毕业设计任务书和指导书范本
框架结构毕业设计任务书和指导书 1 2020年4月19日
毕业设计基本要求 1目的 （1）综合运用所学专业理论知识与设计技能，处理建筑设计中有关方针、政策、功能、经济、安全、美观等方面的问题。解决总体、单体、空间等关系，以创造富有时代气息的优美建筑形象与环境。依据建筑设计完成结构体系的布置、结构在各种荷载工况下的计算、构造和施工图。 （2）掌握一般建筑工程的设计思路，进而举一反三熟悉有关建筑工程的设计、施工、预算等建设过程。为即将走上工作岗位奠定基础。 （3）学以致用，学习科学技术和技能的目的是应用。一个工程师在设计、建设实际工程中应具备的知识，都是我们在毕业设计中应予以加强的。因此深切领悟总体概念设计、掌握具体理论设计和实际工程技术处理措施的结合作为重点来训练。 （4）树立正确的设计思想，全面对待建筑与结构的关系， 2 2020年4月19日
培养勤奋、严谨、认真的工作作风及分析解决一般工程技术问题的能力。 （5）掌握调查研究、理论联系实际的学习方法，养成既能独立思考，又能相互配合密切合作的工作态度。 （6）使学生对一般工业与民用建筑的土建设计的内容和构成有比较全面的了解，并熟悉有关设计标准、规范、手册和工具书，增强毕业后到生产第一线工作的适应能力。 2成果形式及要求 （1）计算书和说明书： 字数应不少于1万字，书写要工整，字迹要清楚，可采用计算机打印。计算书内容要阐明设计依据或标准，方案构思、特点、必要的经济指标，结构选型、构造处理、材料特点及计算上的主要问题，还应包括结构计算全过程，计算要正确、完整、思路清晰、简图明了。计算书格式：应严格按照毕业设计手册中的要求。 （2）图纸： 3 2020年4月19日
土木工程外文文献翻译
专业资料 学院： 专业：土木工程 姓名： 学号： 外文出处：Structural Systems to resist (用外文写) Lateral loads 附件：1.外文资料翻译译文；2.外文原文。
附件1：外文资料翻译译文 抗侧向荷载的结构体系 常用的结构体系 若已测出荷载量达数千万磅重，那么在高层建筑设计中就没有多少可以进行极其复杂的构思余地了。确实，较好的高层建筑普遍具有构思简单、表现明晰的特点。 这并不是说没有进行宏观构思的余地。实际上，正是因为有了这种宏观的构思，新奇的高层建筑体系才得以发展，可能更重要的是：几年以前才出现的一些新概念在今天的技术中已经变得平常了。 如果忽略一些与建筑材料密切相关的概念不谈，高层建筑里最为常用的结构体系便可分为如下几类： 1.抗弯矩框架。 2.支撑框架，包括偏心支撑框架。 3.剪力墙，包括钢板剪力墙。 4.筒中框架。 5.筒中筒结构。 6.核心交互结构。 7. 框格体系或束筒体系。 特别是由于最近趋向于更复杂的建筑形式，同时也需要增加刚度以抵抗几力和地震力，大多数高层建筑都具有由框架、支撑构架、剪力墙和相关体系相结合而构成的体系。而且，就较高的建筑物而言，大多数都是由交互式构件组成三维陈列。 将这些构件结合起来的方法正是高层建筑设计方法的本质。其结合方式需要在考虑环境、功能和费用后再发展，以便提供促使建筑发展达到新高度的有效结构。这并
不是说富于想象力的结构设计就能够创造出伟大建筑。正相反，有许多例优美的建筑仅得到结构工程师适当的支持就被创造出来了，然而，如果没有天赋甚厚的建筑师的创造力的指导，那么，得以发展的就只能是好的结构，并非是伟大的建筑。无论如何，要想创造出高层建筑真正非凡的设计，两者都需要最好的。 虽然在文献中通常可以见到有关这七种体系的全面性讨论，但是在这里还值得进一步讨论。设计方法的本质贯穿于整个讨论。设计方法的本质贯穿于整个讨论中。 抗弯矩框架 抗弯矩框架也许是低，中高度的建筑中常用的体系，它具有线性水平构件和垂直构件在接头处基本刚接之特点。这种框架用作独立的体系，或者和其他体系结合起来使用，以便提供所需要水平荷载抵抗力。对于较高的高层建筑，可能会发现该本系不宜作为独立体系，这是因为在侧向力的作用下难以调动足够的刚度。 我们可以利用STRESS，STRUDL 或者其他大量合适的计算机程序进行结构分析。所谓的门架法分析或悬臂法分析在当今的技术中无一席之地，由于柱梁节点固有柔性，并且由于初步设计应该力求突出体系的弱点，所以在初析中使用框架的中心距尺寸设计是司空惯的。当然，在设计的后期阶段，实际地评价结点的变形很有必要。 支撑框架 支撑框架实际上刚度比抗弯矩框架强，在高层建筑中也得到更广泛的应用。这种体系以其结点处铰接或则接的线性水平构件、垂直构件和斜撑构件而具特色，它通常与其他体系共同用于较高的建筑，并且作为一种独立的体系用在低、中高度的建筑中。
土木工程外文翻译
转型衰退时期的土木工程研究 Sergios Lambropoulosa[1], John-Paris Pantouvakisb, Marina Marinellic 摘要 最近的全球经济和金融危机导致许多国家的经济陷入衰退，特别是在欧盟的周边。这些国家目前面临的民用建筑基础设施的公共投资和私人投资显著收缩，导致在民事特别是在民用建筑方向的失业。因此，在所有国家在经济衰退的专业发展对于土木工程应届毕业生来说是努力和资历的不相称的研究，因为他们很少有机会在实践中积累经验和知识，这些逐渐成为过时的经验和知识。在这种情况下，对于技术性大学在国家经济衰退的计划和实施的土木工程研究大纲的一个实质性的改革势在必行。目的是使毕业生拓宽他们的专业活动的范围，提高他们的就业能力。 在本文中，提出了土木工程研究课程的不断扩大，特别是在发展的光毕业生的潜在的项目，计划和投资组合管理。在这个方向上，一个全面的文献回顾，包括ASCE体为第二十一世纪，IPMA的能力的基础知识，建议在其他：显著增加所提供的模块和项目管理在战略管理中添加新的模块，领导行为，配送管理，组织和环境等；提供足够的专业训练五年的大学的研究；并由专业机构促进应届大学生认证。建议通过改革教学大纲为土木工程研究目前由国家技术提供了例证雅典大学。 1引言 土木工程研究（CES）蓬勃发展，是在第二次世界大战后。土木工程师的出现最初是由重建被摧毁的巨大需求所致，目的是更多和更好的社会追求。但是很快，这种演变一个长期的趋势，因为政府为了努力实现经济发展，采取了全世界的凯恩斯主义的理论，即公共基础设施投资作为动力。首先积极的结果导致公民为了更好的生活条件（住房，旅游等）和增加私人投资基础设施而创造机会。这些现象再国家的发展中尤为为明显。虽然前景并不明朗（例如，世界石油危机在70年代），在80年代领先的国家采用新自由主义经济的方法（如里根经济政策），这是最近的金融危机及金融危机造成的后果（即收缩的基础设施投资，在技术部门的高失业率），消除发展前途无限的误区。 技术教育的大学所认可的大量研究土木工程部。旧学校拓展专业并且新的学校建成，并招收许多学生。由于高的职业声望，薪酬，吸引高质量的学校的学生。在工程量的增加和科学技术的发展，导致到极强的专业性，无论是在研究还是工作当中。结构工程师，液压工程师，交通工程师等，都属于土木工程。试图在不同的国家采用专业性的权利，不同的解决方案，，从一个统一的大学学历和广泛的专业化的一般职业许可证。这个问题在许多其他行业成为关键。国际专业协会的专家和机构所确定的国家性检查机构，经过考试后，他们证明不仅是行业的新来者，而且专家通过时间来确定进展情况。尽管在很多情况下，这些证书虽然没有国家接受，他们赞赏和公认的世界。 在试图改革大学研究（不仅在土木工程）更接近市场需求的过程中，欧盟确定了1999博洛尼亚宣言，它引入了一个二能级系统。第一级度（例如，一个三年的学士）是进入
多层混凝土框架结构设计文献综述
多层混凝土框架结构设计 1.前言 随着社会的发展,钢筋混凝土框架结构的建筑物越来越普遍.由于钢筋混凝土结构与砌体结构相比较具有承载力大、结构自重轻、抗震性能好、建造的工业化程度高等优点；与钢结构相比又具有造价低、材料来源广泛、耐火性好、结构刚度大、使用维修费用低等优点。因此，在我国钢筋混凝土结构是多层框架最常用的结构型式。近年来，世界各地的钢筋混凝土多层框架结构的发展很快，应用很多。 一般框架结构是由楼板、梁、柱及基础4种承重构件组成的，由主梁、柱与基础构成平面框架，各平面框架再由连续梁连接起来而形成的空间结构体系。文献[1]认为，在合理的高度和层数的情况下，框架结构能够提供较大的建筑空间，其平面布置比较的灵活，可适合多种工艺与使用功能的要求。 多层钢筋混凝土框架结构设计可以分为四个阶段：一是方案设计，二是结构分析，三是构件设计，四是绘施工图。结构分析和构件设计是结构设计中的计算阶段，在现代，已由电子计算机承担这一工作，常采用PKPM建模计算。但是，结构的计算并不能代替结构的设计。文献[2]中认为：良好的结构设计的重要前提，应该是合理组织与综合解决结构的传力系统、传力方式，良好的结构方案是良好结构设计的重要前提。2.关于框架结构设计文献回顾 2.1框架结构的优缺点 框架结构体系是由横梁与柱子连接而成.梁柱连接处(称为节点)一般为刚性连接,有时为便于施工和其他构造要求,也可以将部分节点做成铰接或者半铰接.柱支座一般为固定支座,必要时也可以设计成铰支座.框架结构可以分为现浇整体式,装配式,现浇装配式. 文献[3]中提到:框架结构的布置灵活,容易满足建筑功能和生工艺的多种要求.同时,经过合理设计,框架结构可以具有较好的延性和抗震性能.但是,框架结构承受水平力(如风荷载和水平地震作用)的能力较小.当层树较多或水平力较大时,水平位移较大,在强烈地震作用下往往由于变形过大而引起非结构构件(如填充墙)的破坏.因此,为了满足承载力和侧向刚度的要求,柱子的截面往往较大,既耗费建筑材料,又减少使用面积.这就使框架结构的建筑高度受到一定的限制.目前,框架结构一般用于多层建筑和不考虑抗震设防,层数较少的的高层建筑(比如,层数为10层或高度为30米以下) 2.3框架结构的布置 多层框架结构的平面布置形式非常的灵活，文献[4]中将框架结构按照承重方式的不同分为以下三类：(1)横向框架承重方案,以框架横梁作为楼盖的主梁,楼面荷载主要由横向框架承担.由于横向框架数往往较少,主梁沿横向布置有利于增强房屋的横向刚度.同时,主梁沿横向布置还有利于建筑物的通风和采光.但由于主梁截面尺寸较大,当房屋需要大空间时,净空较小,且不利于布置纵向管道. (2)纵向框架承重方案以框架纵梁作为楼盖的主梁,楼面荷载由框架纵梁承担.由于横梁截面尺寸较小,有
框架结构设计外文翻译
毕业设计(论文)外文资料翻译 系：机械工程系 专业：土木工程 姓名： 学号： 外文出处：Design of prestressed (用外文写) concrete structures 附件： 1.外文资料翻译译文；2.外文原文。
附件1：外文资料翻译译文 8-2简支梁布局 一个简单的预应力混凝土梁由两个危险截面控制：最大弯矩截面和端截面。这两部分设计好之后，中间截面一定要单独检查，必要时其他部位也要单独调查。最大弯矩截面在以下两种荷载阶段为控制情况，即传递时梁受最小弯矩M G的初始阶段和最大设计弯矩M T时的工作荷载阶段。而端截面则由抗剪强度、支承垫板、锚头间距和千斤顶净空所需要的面积来决定。所有的中间截面是由一个或多个上述要求，根它们与上述两种危险截面的距离来控制。对于后张构件的一种常见的布置方式是在最大弯矩截面采用诸如I形或T形的截面，而在接近梁端处逐渐过渡到简单的矩形截面。这就是人们通常所说的后张构件的端块。对于用长线法生产的先张构件，为了便于生产，全部只用一种等截面，其截面形状则可以为I形、双T形或空心的。在第5 、 6 和7章节中已经阐明了个别截面的设计，下面论述简支梁钢索的总布置。 梁的布置可以用变化混凝土和钢筋的办法来调整。混凝土的截面在高度、宽度、形状和梁底面或者顶面的曲率方面都可以有变化。而钢筋只在面积方面有所变化，不过在相对于混凝土重心轴线的位置方面却多半可以有变化。通过调整这些变化因素，布置方案可能有许多组合，以适应不同的荷载情况。这一点是与钢筋混凝土梁是完全不同的，在钢筋混凝土梁的通常布置中，不是一个统一的矩形截面便是一个统一的T形，而钢筋的位置总是布置得尽量靠底面纤维。 首先考虑先张梁，如图 8-7，这里最好采用直线钢索，因为它们在两个台座之间加力比较容易。我们先从图（a）的等截面直梁的直线钢索开始讨论。这样的布置都很简单，但这样一来，就不是很经济的设计了，因为跨中和梁端的要求会产生冲突。通常发生在跨度中央的最大弯矩截面中的钢索，最好尽量放低，以便尽可能提供最大力臂而提供最大的内部抵制力矩。当跨度中央的梁自重弯矩M G相当大时，就可以把c.g.s布置在截面核心范围以下很远的地方，而不致在传递时在顶部纤维中引起拉应力。然而对于梁端截面却有一套完全不同的要求。由于在梁端没有外力矩，因为在最后的时刻，安排钢索要以c.g.s与 c.g.c在结束区段一致，如此同样地获得克服压力分配的方法。无论如何，如果张应力在最后不能承受，放置 c.g.s.
三大框架的优缺点
Struts的优点有： 1.实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现. 2.有丰富的tag可以用,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。 3.页面导航.页面导航将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。 4.提供Exception处理机制. 5.数据库链接池管理 6.支持I18N 缺点： 一、转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcat这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样，几十上百个人同时在线使用我们的系统，大家可以想象一下，我的烦恼有多大。 二、Struts的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。 三、测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。 四、类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。 五、对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest和ServletResponse，所有它摆脱不了Servlet容器。
拓言新辞：只给会专业英语的人“面包”吃
拓言新辞：只给会专业英语的人“面包”吃 来源：i黑马发布时间：2013-7-19 【导读】拓言新辞是一家面向中小企业的众包翻译平台，主要从事文档、视频和APP等内容的翻译。上线三个月，这个只有几个人的小团队就获得了10万美元的单子，而创始人钟卫的野心更大：盯上阿里巴巴商贸通上的500万外贸商户。 翻译有着悠久的历史，譬如希伯来文的基督教经典《圣经旧约》在公元前280年左右就开始被翻译为希腊文，有些人甚至断言没有翻译便没有现在的欧洲文化。而互联网也正给这个古老的行当带来“众包”这一新的工作方法——互联网海选译者，再由多人以最短时间合作翻译，比如曾经风靡一时的著作《史蒂夫·乔布斯传》便是由译言网通过众包给网友的形式，在不到20天的时间里完成的。国内类似的网站还有很多，比如译言的姊妹网站东西网、体育媒体虎扑和科技媒体果壳网。今天黑马哥为大家带来的黑马“拓言新辞”(英文名字Ratonwork)便是这个行业的新秀，它也是黑马大赛的角逐者。 “Ratonwork是一家基于众包模式的专业翻译服务平台，面向个人、机构、中小企业提供专业化的翻译服务。”这是在自己的商业计划书中，创始人钟卫给Ratonwork这个创立刚刚一年的公司甚是清晰的定位。相对来说，钟前期的个人经历并没有Ratonwork这么顺畅，毕业于山东科技大学的他2001年便开始北漂生涯，做过程序员，也做过项目经理，干过技术代理，干做过人口数据管理。 直到2005年，钟卫才找到一份儿比较稳定的工作——在微软做技术经理，之后又担任了市场专员一职，负责技术布道及市场推广。
担纲微软的IT人社交网站https://www.wendangku.net/doc/a217823133.html,的建设期间，钟遇到了英文培训课程翻译和软件汉化的问题，“一方面一些专业人员想通过阅读或者翻译来不断学习，另一方面一些IT企业对专业翻译有需求。”在他的描述中，这一问题是他创业的直接诱因。 2012年3月，在众包翻译业风生水起的大环境下，钟卫选择了从微软辞职创业。2012年10月，他的众包翻译平台Ratonwork上线。 以下为钟卫口述： “传递面包” 我们不做软件等产品级的翻译，主要做文档、资料、视频和电子教学等内容的翻译，还有一些APP的中翻英。企业客户可以把需要翻译的内容放到我们的网络平台上，之后译者在平台上认领。 视频翻译主要有产品视频、技术视频和教育视频三种。我们做两个事，一个是翻译字幕，做字幕托管，他可以把视频的地址给我，我直接在视频上翻译，在原有的基础上做一个代码就可以适配到我的字幕。另一个模式，如果他没有视频，他可以把视频传给我，我们做好字幕后把播放器的地址给他，这样他也不需要找空间上传，直接引用就可以。现在企业客户就是怕麻烦，把所有的事情给他做简单了，他是最开心的。 我们的策略是先拿大客户，一个行业的大客户就那么几家，做好之后身边的人就开始帮你卖了，口碑很重要，一个是客户口碑，还有就是译者的口碑。译者帮你做东西，如果他觉得你对他还不错，他会把他身后的公司带给你，这是我们没有想到的。“发动农民斗地主”，
框架结构文献综述
浅谈我国多层混凝土框架结构设计1.前言 随着社会的发展,钢筋混凝土框架结构的建筑物越来越普遍.由于钢筋混凝土结构与砌体结构相比较具有承 载力大、结构自重轻、抗震性能好、建造的工业化程度高等优点；与钢结构相比又具有造价低、材料来源广泛、耐火性好、结构刚度大、使用维修费用低等优点。因此，在我国钢筋混凝土结构是多层框架最常用的结构型式。近年来，世界各地的钢筋混凝土多层框架结构的发展很快，应用很多。 一般框架结构是由楼板、梁、柱及基础4种承重构件组成的，由主梁、柱与基础构成平面框架，各平面框架再由连续梁连接起来而形成的空间结构体系。文献[1]认为，在合理的高度和层数的情况下，框架结构能够提供较大的建筑空间，其平面布置比较的灵活，可适合多种工艺与使用功能的要求。 多层钢筋混凝土框架结构设计可以分为四个阶段：一是方案设计，二是结构分析，三是构件设计，四是绘施工图。结构分析和构件设计是结构设计中的计算阶段，在现代，已由电子计算机承担这一工作，常采用PKPM建模计算。但是，结构的计算并不能代替结构的设计。文献[2]中认为：良好的结构设计的重要前提，应该是合理组织与综合解决结构的传力系统、传力方式，良好的结构方案是良好结构设计的重要前提。 2.关于框架结构设计文献回顾 2.1框架结构的优缺点 框架结构体系是由横梁与柱子连接而成.梁柱连接处(称为节点)一般为刚性连接,有时为便于施工和其他构 造要求,也可以将部分节点做成铰接或者半铰接.柱支座一般为固定支座,必要时也可以设计成铰支座.框架结构可以分为现浇整体式,装配式,现浇装配式. 文献[3]中提到:框架结构的布置灵活,容易满足建筑功能和生工艺的多种要求.同时,经过合理设计,框架结构 可以具有较好的延性和抗震性能.但是,框架结构承受水平力(如风荷载和水平地震作用)的能力较小.当层树 较多或水平力较大时,水平位移较大,在强烈地震作用下往往由于变形过大而引起非结构构件(如填充墙)的 破坏.因此,为了满足承载力和侧向刚度的要求,柱子的截面往往较大,既耗费建筑材料,又减少使用面积.这就 使框架结构的建筑高度受到一定的限制.目前,框架结构一般用于多层建筑和不考虑抗震设防,层数较少的的高层建筑(比如,层数为10层或高度为30米以下) 2.3框架结构的布置 多层框架结构的平面布置形式非常的灵活，文献[4]中将框架结构按照承重方式的不同分为以下三类：(1)横向框架承重方案,以框架横梁作为楼盖的主梁,楼面荷载主要由横向框架承担.由于横向框架数往往较少,主梁沿横向布置有利于增强房屋的横向刚度.同时,主梁沿横向布置还有利于建筑物的通风和采光.但由于主梁截面尺寸较大,当房屋需要大空间时,净空较小,且不利于布置纵向管道.
框架结构外文翻译
南京工程学院毕业设计 外文资料翻译 学生姓名：顾建祥 学号： 240095319 班级名称： K建工ZB093 所在院系：康尼学院
Underground Space Utilization The rapid growth of world civilization will have a significant impact on the way humans live in the future. As the global population increases and more countries demand a higher standard of living, the difficulty of doing this is compounded by three broad trends: the conversion of agricultural land to development uses; the increasing urbanization of the world`s population; and growing concern for the maintenance and improvement of the environment, especially regarding global warming and the impact of population growth. Underground space utilization, as this chapter describes, offers opportunities for helping address these trends. By moving certain facilities and function underground, surface land in urban areas can be used more effectively , thus freeing space for agricultural and recreational purpose. Similarly, the use of terraced earth sheltered housing. Using underground space also enables humans to live more comfortably in densely populated areas while improving the quality of live. On an urban or local level, the use of underground facilities is rising to accommodate the complex demands of today`s society while improving the environment . For example, both urban and rural areas are requiring improved transportation, utility, and recreational services. The state of traffic congestion in many urban areas of the world is at a critical level for the support of basic human living, and it is difficult if not impossible to add new infrastructure at ground level without causing an unacceptable deterioration of the surface environment or an unacceptable relocation of existing land uses and neighborhoods. On a national level in countries around the world, global trends are causing the creation and extension of mining developments and oil or gas recovery at greater depths and in more inaccessible or sensitive locations. Three trends have also led to the developments of improved designs for
整合SSH三大框架介绍
一.在MyEclipse里先建立一个Web project 的项目，选最新版本的java ee。 二.添加struts2框架支持 1.引入struts2必须得几个jar包，放在WebRoot->WEB-INF->lib 目录下。 2.将WEB应用部署到tomcat服务器上：找到tomacat的安装目录Tomcat6.x\apache-tomcat-6.0.33\conf，打开其中的server.xml文件，在文件末尾上面加入例如
器将部署好的应用纳入到struts2的管辖范围类，具体代码如下
土木工程毕业设计文献综述钢筋混凝土框架结构
文献综述 钢筋混凝土框架结构 1.前言 随着经济的发展、科技进步、建筑要求的提升，钢筋混凝土结构在建筑行业得到了迅速发展。随着建筑造型和建筑功能要求日趋多样化，无论是工业建筑还是民用建筑，在结构设计中遇到的各种难题日益增多，钢筋混凝土结构以其界面高度小自重轻，刚度大，承载能力强、延性好好等优点，被广泛应用于各国工程中，特别是桥梁结构、高层建筑及大跨度结构等领域，已取得了良好的经济效益和社会效益。而框架结构具有建筑平面布置灵活、自重轻等优点，可以形成较大的使用空间，易于满足多功能的使用要求，因此，框架结构在结构设计中应用甚广。为了增强结构的抗震能力，框架结构在设计时应遵循以下原则：“强柱弱梁、强剪弱弯、强节点强锚固”。 2.现行主要研究 2.1预应力装配框架结构 后浇整体节点与现浇节点具有相同的抗震能力;钢纤维混凝土对减少节点区箍筋用量有益,但对节点强度、延性和耗能的提高作用不明显。与现浇混凝土节点相比,预应力装配节点在大变形后强度和刚度的衰减及残余变形都小;节点恢复能力强;预制混凝土无粘结预应力拼接节点耗能较小,损伤、强度损失和残余变形也较小。装配节点力学性能受具体构造影响很大,过去进行的研究也较少,一般说,焊接节点整体性好,强度、耗能、延性等方面均可达到现浇节点水平;螺栓连接节点刚度弱,变形能力大,整体性较差。因此,这一类节点连接如应用于抗震区,需做专门抗震设计。 2.2地震破坏 钢筋混凝土在地震破坏过程中瞬态震动周期逐步延长，地震动的低频成分是加剧结构破坏的主要因素，峰值和持时也是非常重要的原因。瞬态振型的变化与结构的破坏部位直接相关。结构破坏过程中，瞬态振型参与系数变化不大。结构瞬态振动周期
外文翻译(结构设计背景)
第三部分：外文翻译 结构设计背景 Background for Structural Design 1. Practice versus Theory We hear much of the conflict between theory and practice. Actually, of course, there will be no conflict between good theory and good practice, although the two frequently seem at cross-purposes, particularly when both are bad. Bad theory develops from unjustifiably crude assumptions, while bad practice follows unjustifiably crude methods. When theory can be based upon correct premises and practice can be controlled by one who understands the theory involved, the two will agree. Nevertheless, there are certain considerations of practice that must be allowed to control design, particularly to facilitate construction. A few of the many problems that should influence the thinking of the designer and of the construction engineer will be discussed. 2. Analytical Calculations Since analysis precedes design, it will be useful to think over the process of analysis from the point of view of the practical designer. Analysis, to serve a useful purpose, must finally reach expression in terms of tons of steel, cubic yards of concrete, and board feet of structural timber. It is useless for the analyst or the designer to expect the construction engineer to worry about increasing the unit stress in a steel beam by a few hundred pounds per square inch above the allowable stress by the shifting of a partition. The field man knows that there are decisions he will have to make during erection that may influence the stress to a greater extent than the amount mentioned. For the same reason, he is not likely to be sympathetic when the blueprint carries a statement that a field connection is to be welded at a distance of 5 j ^ in. from a sheared edge.
- 框架结构外文翻译
- 框架结构的抗震设计思路外文翻译
- 哈佛分析框架 外文文献及翻译
- 土木工程外文翻译70683
- 信息与计算科学中英文对照外文翻译文献
- 土木工程外文翻译
- 毕业设计--某五层框架结构学生宿舍设计(含外文翻译)
- 外文翻译-框架结构设计
- 图书馆框架结构设计外文翻译六
- 框架结构外文翻译分析解析
- (完整版)框架结构_毕业设计外文文献翻译_(外文原文中文翻译_)
- 写字楼框架结构设计文献综述+开题报告+外文翻译
- 写字楼框架结构设计文献综述+开题报告+外文翻译
- 框架结构毕业设计开题报告样本
- 写字楼框架结构设计文献综述+开题报告+外文翻译
- B.S结构外文翻译
- 5层框架结构教学楼毕业设计计算书(含外文翻译)
- 土木工程框架结构设计开题报告文献综述外文翻译
- 框架结构毕业设计开题报告
- 框架结构设计外文翻译