J2EE最佳实践： Middleware公司开发指南

j2ee

需积分: 9 138 浏览量更新于2024-07-24 收藏 4.28MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"J2EE Best Practices - Middleware company提供的开发J2EE项目的最佳实践，是J2EE学习的经典资料。" J2EE（Java 2 Platform, Enterprise Edition）是Oracle公司推出的用于构建企业级分布式应用程序的平台，它为开发和部署多层架构的应用提供了丰富的组件和服务。"J2EE Best Practices" 提供的是在开发J2EE项目时遵循的最佳实践，旨在帮助开发者提高效率，减少错误，确保应用的可扩展性、稳定性和安全性。 1. **模块化设计**：J2EE应用通常由多个模块组成，如EJB（Enterprise JavaBeans）、Web组件（Servlets和JSP）以及持久层（JPA或Hibernate）。最佳实践建议将业务逻辑、数据访问和展示层分离，以实现良好的解耦和可维护性。 2. **EJB与微服务**：EJB作为J2EE的核心组件，负责处理事务、安全性和并发。最佳实践提倡根据业务需求选择合适的服务粒度，现在微服务架构也日益流行，对于复杂系统，可以考虑将EJB拆分为更小的服务。 3. **容器管理的事务**：J2EE容器提供了事务管理服务，开发者应充分利用这些服务，而不是手动管理事务，以降低出错风险并提高代码的可读性。 4. **使用MVC模式**：在Web层，模型-视图-控制器（MVC）模式是最佳实践，它有助于保持前端和后端逻辑的清晰。 5. **数据访问优化**：使用JPA或Hibernate等ORM（对象关系映射）工具可以简化数据库操作，但需注意性能调优，避免N+1查询、过度使用JOIN等常见问题。 6. **安全性**：J2EE提供了一套全面的安全框架，包括认证、授权和加密。开发者应了解如何正确配置这些功能，以保护应用免受攻击。 7. **负载均衡与集群**：为了提高可用性和容错性，J2EE应用常常部署在集群环境中。理解如何配置负载均衡策略和故障转移机制至关重要。 8. **测试与持续集成**：采用TDD（测试驱动开发）和自动化测试工具，如JUnit和Selenium，确保代码质量。同时，结合Jenkins或GitLab CI/CD实现持续集成和部署，加速开发流程。 9. **性能监控**：利用JMX（Java Management Extensions）和其他监控工具，持续监控应用性能，及时发现并解决问题。 10. **文档和版本控制**：保持良好的文档记录，使用版本控制系统如Git，以促进团队协作和版本管理。 Wiley Publishing, Inc. 提供了一系列技术书籍，针对不同学习风格和经验层次的读者，如“Dummies”系列适合初学者，"The Bible"系列提供详尽教程和参考。通过这些资源，开发者能够深入学习J2EE，提升专业技能。访问www.wiley.com/compbook可以查看更多的IT专业书籍，继续扩大知识领域。

资源详情

资源推荐

Building Business Applications with J2EE xv

utilize the J2EE component-based services without changing the object-oriented view

of the world very much at all. In the case of stateless Session Beans, you also gain these

benefits without adding much overhead to the processing time. The session façade act-

ing as an EJB component wrapper around a service implementation object is referred

to as the Service Component pattern in the reference architecture.

Figure I.2 illustrates the UML representation of this service component pattern.

The business objects and presentation components also contain numerous examples

of proven design patterns that can be applied. The Template Method pattern (Gamma

et al. 1995) provides an excellent mechanism for providing extensible foundation com-

ponents for both business objects and service objects. In the case of business objects, it

provides a template for common operations such as a save operation to cause the

object’s data to persist in the database. The base class, or template, provides hooks for

subclasses, the specific business objects, to implement validation rules and presave or

postsave logic. Enterprise JavaBeans uses a number of design patterns applied to the

Java language. Some of them are variations of existing patterns that use Java interfaces,

such as with Entity Beans. Entity Beans must implement a common interface

javax.ejb.EntityBean that provides hooks for insert, update, and delete logic.

Each architecture layer discussed builds on these existing patterns and looks at some

additional patterns that provide flexibility and reusability within the software archi-

tecture on top of J2EE.

Figure I.2 UML Diagram of Service Component Pattern.

MyBusinessObject1

Attribute1:String

Attribute2:String

businessMethod1()

businessMethod2()

MyBusinessObject2

Attribute1:String

Attribute2:String

businessMethod1()

businessMethod2()

ServiceImpl

doService()

ServiceEJBWrapper

executeService()

Business Object

Packages

xvi J2EE Best Practices: Java Design Pattens, Automation, and Performance

Automating Common Functions

The approach of automating common functions provides a number of benefits:

Time is not wasted on monotonous, error-prone tasks.

A higher-quality product through better-tested software; there is less total code

to run through and it gets hit on every request; in essence, the foundation of

much of the processing becomes a black box process with inputs.

Automated functions and their common interfaces make it easier to develop

and maintain consistent software across the application.

Even with easy-to-use APIs such as the Java servlet API, there are still many func-

tions that must always be done in an application. For example, one of the common

elements of business applications is the ability to process user form submissions. On

each of these requests, the data from the form submission needs to be read out of the

HttpServletRequest object, packaged in some data structures, and sent to the

requested service or back-end function. One alternative is to write a custom servlet or

JSP to handle every form on all pages. This usually isn’t very efficient because the num-

ber of forms in a typical business application is relatively high. You might find that the

logic to handle each form is repetitive and even has the same blocks of code in it. The

other alternative is to abstract the basic flow of handling a form request and put it into

a common servlet that can be used by all of the Web pages that have forms. Using a

configuration service, you could define each form, its input data, and a service that

should be used to process the request. Almost any function or process that is repeatable

is a candidate for automation. This book looks at the nature of transactional Web ap-

plications in order to define a set of common elements that can be automated. As it

turns out, due to the nature of Web applications and J2EE application architectures,

many of these common elements need to be implemented for any given application. A

set of configurable foundation components that implement these functions will

increase both the quality and quantity of application functionality built on the

reference architecture. As this book goes through the process of discussing the set of

common elements and applying them to the Java platform, additional requirements

for this foundation layer will be flushed out. Some basic work can be done at this level

that provides immense value in meeting the overall goals of a scalable, modular

architecture.

A set of configurable foundation components that automate basic elements of an ap-

plication is often referred to as a framework. Building upon an earlier principle, many

of these foundation components will be implemented using proven object-oriented

design patterns. These framework components and patterns are what make up the ref-

erence architecture that will be used to rapidly develop quality J2EE applications. As

many developers know, there is a gap between the total sum of services needed to de-

velop just purely application-specific logic and those that are currently provided with

the development platform. A software layer, referred to in this book as the Business

Logic Foundation (BLF), will attempt to bridge this gap. The Java and J2EE platform

continues to evolve and close the gap. However, it still remains even as a large number

of people and organizations are working to add services to the platform. Due to the

complexity of enterprise development, the widely varying set of requirements that dif-

Building Business Applications with J2EE xvii

ferent businesses and organizations have, and the many design considerations, it will

take a significant amount of time for the standard to mature to the point where it ad-

dresses all of these needs. In fact, even as the underlying platforms and standards

evolve, technology and problem domains also grow, thus making it likely that closing

the gap will resemble a calculus equation represented by a curve which slowly ap-

proaches zero, but never actually gets there.

The automation capabilities within technical frameworks provide a high level of

reusability across applications. Reusability is of course the “Holy Grail” of object-

oriented software development. However, it has been very hard to achieve in many

practical settings. Given a strategic application architecture and the set of guiding

principles, you can position yourself to benefit from software reuse. The Enterprise

JavaBean specification goes a long way toward having standard, reusable business

components across applications. However, it is the role of the application architecture

on top of J2EE to enable those components to be reused. It is important to have an ap-

plication architecture that easily allows components to be plugged in to the rest of the

system without adding significant overhead.

One way to plug in different components is through a messaging layer that buffers

the different interfaces and systems. In complex architectures, this is the right solution,

but for many applications, the overhead is too much of a price to pay. Two primary

strategies to promote and enable the reuse of domain components are realized through

the first two principles, design patterns and automated foundation components. One

such example is that of the Service-Based Architecture layer that provides a standard

interface for process-based components. By creating a standard interface that is used

by the user presentation layer, a service such as Retrieve Account Data can be reused

from different screens that require customer data. Services such as Account Deposit

and Account Withdrawal can be reused as building blocks in an overall service, Trans-

fer Funds. The fact that there is a service layer at all in the architecture allows the ser-

vices themselves to be reused from different client devices. Finally, the standard

interface of the service components allows you to automate their invocation through a

configurable foundation layer within the reference architecture.

Use Metadata-Driven Components

Metadata is usually defined as data that describes other data. This book also uses the

term “metadata” to refer to the many data elements that define the attributes and

behaviors of various software components. Some examples of this could be the list of

properties and their respective data types for a given business object, or it could be the

form name and associated configuration information for a Web page. Much of the

metadata that defines these components comes from design models described in UML.

The principle of using metadata to drive components again builds upon a previous

principle, that of automating the tasks of software development. Metadata is used as

an input to the “framework” services that automate and drive the behavior of J2EE

components. This is applicable at all levels of the architecture. In the case of business

objects, metadata can be used to define the business entities and their attributes. At the

workflow or transaction level, metadata can be used to drive the process flow of

complicated tasks. At the user interface level, it can define a particular Web page form

xviii J2EE Best Practices: Java Design Pattens, Automation, and Performance

and how it should be processed. All of these elements of applications can be abstracted

and defined using metadata. The J2EE specifications themselves rely on different

forms of metadata to configure and deploy components. A perfect example is the ab-

stract approach taken by EJB 2.0 toward Container-Managed Persistence (CMP). The

EJB deployment descriptors contain the metadata that maps the bean’s properties to

database tables, as well as defining any relationships that the bean may have with

other components.

Not every process or function should be defined using metadata (everything in

moderation, as they say). There are some drawbacks to this approach that should be

considered and that may not make it the right approach for every task. A metadata-

driven abstraction usually will add some overhead to the execution of the task when

compared to explicit lines of code used to do the same job. This overhead is typically

negligible when compared to something like a single database I/O request. However,

it should be considered nonetheless in the overall approach to software development,

especially where transaction throughput is essential to the success of an application.

Another potential drawback of this approach is the fact that it can make reading and

debugging code a bit more difficult. A separate file or repository that contains the

metadata determines portions of the flow through the code. There are a number of ar-

guments to counteract this point, some of which have been mentioned here already.

The primary argument is that these foundation components, which are configurable

through metadata, become highly tested components that become almost like a black

box to the rest of the application. Once you have these components working correctly,

very little time is spent looking at the “framework” code. The behavior of an applica-

tion can be determined simply by looking at the client code and the metadata inputs

to the service. Consistent use of these foundation components rapidly makes this

contention less of an issue. Another less structured argument is that well-written

object-oriented code is difficult to sit down and read in the first place because the meth-

ods are typically very small and you often have to jump back and forth from object

to object anyway in order to decipher what is going on. This issue was dealt with on a

different level when software development moved in large part from procedural code

to object-oriented development. It is usually easier to read and understand a contigu-

ous block of procedural code than it is object-oriented code, but the many benefits

found in OO development far outweigh this minor and perhaps even debatable disad-

vantage. Some of these same arguments apply to a metadata-driven approach as well.

As in many aspects of the J2EE architecture, both the pros and the cons must be

weighed for a given design decision before making a choice. As is the case with so

many architecture decisions you will see, the solution is often a middle-of-the-road

choice in which metadata is used for key components that provide the maximum ben-

efit. Elements of business applications that are data intensive and heavily used, such as

forms processing and business object persistence, will use metadata to rapidly develop

quality implementations.

The industry seems to be moving to storing many pieces of data in XML format, and

metadata is no exception. Storing metadata as XML provides a number of benefits:

XML data provides a standard format that can be stored either in a file or in a

database table.

Building Business Applications with J2EE xix

Most design tools can generate XML data from their models; many tools now

support XMI (XML Metadata Interchange), a standard XML format for object

metadata.

XML can be created or modified using a number of different tools including

XML editors, custom-written tools, or in many cases, even a simple text editor.

An interesting effect of using metadata is that it separates pieces of the application

design from the code. This is helpful for a number of reasons:

A higher number of application functions driven by the design imply that

fewer application changes will require actual code changes. This increases the

speed of maintenance cycles and deployment.

XML supports a model-driven development approach; the design models

become accurate pieces of documentation for the system and are used to

generate application components or the metadata input to foundation

components.

Much of the input to application code can originate from design models.

The object models for the business entities contain the properties and the

relationships between the entities. This metadata can be exported from design

tools into XML. The XMI specification provides one such format to do so, and

design tools are starting to support it. If a configurable business object base

class can manage the properties and relationships for a business object, you

have now automated this portion of the business object through metadata

input almost completely through the design process. Of course, specific

business methods and other application components will also modify the

properties of the business object and create instances of relationships, but the

logic to do so has been automated through the metadata-driven process.

Practicality: Performance and Scalability

The last principle, essentially performance engineering, is one that underlies all else.

Avoiding this topic until the final phases of any project can have serious consequences.

The quickest thing (no pun intended!) that will keep people from using your system is

poor performance, especially in today’s fast-paced Internet world. Business application

users are accustomed to the performance of client-server applications over private net-

works and consumers or Internet users are very impatient when it comes to waiting for a

Web-site page to load. Thus, although it is true that computers are getting faster and more

hardware is always an option (if you built a scalable solution), you must keep a watchful

eye and build performance into the development process from the very beginning. It

must be a part of the design process because it often involves trade-offs with other as-

pects of a system, most often the flexibility that an application provides to the user.

Java, the language itself, can quickly approach the performance of C/C++ in many

situations, a language widely regarded as a high-performance choice for even the most

demanding applications. This is primarily due to the evolution of just-in-time (JIT) com-

pilers that now aggressively translate Java byte code and perform code optimizations.

剩余495页未读，继续阅读

bluebelfast

粉丝: 131
资源: 26

J2EE最佳实践： Middleware公司开发指南

Core j2ee Patterns Best Practices And Design Strategies

Core J2EE Patterns - Best Practices and Design Strategies - 2nd Edition

cmake best practices pdf

简要概括 XEP-0160 Best Practices for Handling Offline Messages

Write an article sharing your experience on important principles, development paradigms and best practices in software development, generating chapters and main entries with as much detail as possible and at least 5000 words

能不能找出那种专著类型的参考文献至少三个外文的，跟Java，JavaEE有关的并且是2018年以后的

PABP-PCE PABP-OCE

关于springboot框架的外文文献有哪些

sap最佳业务实践 在哪里下载

Practices.EnterpriseLibrary.Logging的使用方式

给我找两篇英文文献有关于Java或者springboot框架或者vue的

helm charts 学习文档

arm linux webser

Key practices for extreme programming

The 'viewport' meta element 'content' attribute value should not contain 'minimum-scale'

What is the principle of least privilege? Why does this principle matter?

Please refer to C:\Users\lenovo\Desktop\大学\大三\企业级应用框架与管理\实验\MakeFriends\target\surefire-reports for the individual test results.

Microsoft.Practices.Unity 迁移成 Autofac 详细代码

solidity ref

最新资源

sap最佳业务实践在哪里下载