Context
Entity beans are not intended to represent every persistent object in the object model.
Entity beans are better suited for coarse-grained persistent business objects.
Problem
In a Java 2 Platform, Enterprise Edition (J2EE) application, clients -- such as
applications, JavaServer Pages (JSP) pages, servlets, JavaBeans components -- access entity
beans via their remote interfaces. Thus, every client invocation potentially routes through
network stubs and skeletons, even if the client and the enterprise bean are in the same JVM,
OS, or machine. When entity beans are fine-grained objects, clients tend to invoke more
individual entity bean methods, resulting in high network overhead.
Entity beans represent distributed persistent business objects. Whether developing or
migrating an application to the J2EE platform, object granularity is very important when
deciding what to implement as an entity bean. Entity beans should represent coarse-grained
business objects, such as those that provide complex behavior beyond simply getting and
setting field values. These coarse-grained objects typically have dependent objects. A
dependent object is an object that has no real domain meaning when not associated with its
coarse-grained parent.
A recurring problem is the direct mapping of the object model to an Enterprise
JavaBeans (EJB) model (specifically entity beans). This creates a relationship between the
entity bean objects without consideration of coarse-grained versus fine-grained (or
dependent) objects. Determining what to make coarse-grained versus fine-grained is
typically difficult and can best be done via modeling relationships in Unified Modeling
Language (UML) models.
There are a number of areas impacted by the fine-grained entity bean design
approach:
Entity Relationships - Directly mapping an object model to an EJB model does not
take into account the impact of relationships between the objects. The inter-object
relationships are directly transformed into inter-entity bean relationships. As a result, an
entity bean might contain or hold a remote reference to another entity bean. However,
maintaining remote references to distributed objects involves different techniques and
semantics than maintaining references to local objects. Besides increasing the complexity of
the code, it reduces flexibility, because the entity bean must change if there are any changes
in its relationships.
Also, there is no guarantee as to the validity of the entity bean references to other
entity beans over time. Such references are established dynamically using the entity's home
object and the primary key for that entity bean instance. This implies a high maintenance
overhead of reference validity checking for each such entity-bean-to-entity-bean reference.
Manageability - Implementing fine-grained objects as entity beans results in a large
number of entity beans in the system. An entity bean is defined using several classes. For
each entity bean component, the developer must provide classes for the home interface, the
remote interface, the bean implementation, and the primary key.
In addition, the container may generate classes to support the entity bean
implementation. When the bean is created, these classes are realized as real objects in the
container. In short, the container creates a number of objects to support each entity bean
instance. Large numbers of entity beans result in more classes and code to maintain for the
development team. It also results in a large number of objects in the container. This can
negatively impact the application performance.
Network Performance - Fine-grained entity beans potentially have more inter-entity
bean relationships. Entity beans are distributed objects. When one entity bean invokes a
method on another entity bean, the call is potentially treated as a remote call by the
container, even if both entity beans are in the same container or JVM. If the number of
entity-bean-to-entity-bean relationships increases, then this decreases system scalability due
to heavy network overhead.
Database Schema Dependency - When the entity beans are fine-grained, each entity
bean instance usually represents a single row in a database. This is not a proper application
of the entity bean design, since entity beans are more suitable for coarse-grained
components. Fine-grained entity bean implementation typically is a direct representation of
the underlying database schema in the entity bean design. When clients use these
fine-grained entity beans, they are essentially operating at the row level in the database,
since each entity bean is effectively a single row. Because the entity bean directly models a
single database row, the clients become dependent on the database schema. When the
schema changes, the entity bean definitions must change as well. Further, since the clients
are operating at the same granularity, they must observe and react to this change. This
schema dependency causes a loss of flexibility and increases the maintenance overhead
whenever schema changes are required.
Object Granularity (Coarse-Grained versus Fine-Grained) - Object granularity
impacts data transfer between the enterprise bean and the client. In most applications,
clients typically need a larger chunk of data than one or two rows from a table. In such a
case, implementing each of these fine-grained objects as an entity bean means that the client
would have to manage the relationships between all these fine-grained objects. Depending
on the data requirements, the client might have to perform many lookups of a number of
entity beans to obtain the required information.
Forces
Entity beans are best implemented as coarse-grained objects due to the high overhead
associated with each entity bean. Each entity bean is implemented using several objects,
such as EJB home object, remote object, bean implementation, and primary key, and each is
managed by the container services.
Applications that directly map relational database schema to entity beans (where each
row in a table is represented by an entity bean instance) tend to have a large number of
fine-grained entity beans. It is desirable to keep the entity beans coarse-grained and reduce
the number of entity beans in the application.
Direct mapping of object model to EJB model yields fine-grained entity beans.
Fine-grained entity beans usually map to the database schema. This entity-to-database row
mapping causes problems related to performance, manageability, security, and transaction
handling. Relationships between tables are implemented as relationships between entity
beans, which means that entity beans hold references to other entity beans to implement the
fine-grained relationships. It is very expensive to manage inter-entity bean relationships,
because these relationships must be established dynamically, using the entity home objects
and the enterprise beans' primary keys.
Clients do not need to know the implementation of the database schema to use and
support the entity beans. With fine-grained entity beans, the mapping is usually done so that
each entity bean instance maps to a single row in the database. This fine-grained mapping
creates a dependency between the client and the underlying database schema, since the
clients deal with the fine-grained beans and they are essentially a direct representation of
the underlying schema. This results in tight coupling between the database schema and
entity beans. A change to the schema causes a corresponding change to the entity bean, and
in addition requires a corresponding change to the clients.
There is an increase in chattiness of applications due to intercommunication among
fine-grained entity beans. Excessive inter-entity bean communication often leads to a
performance bottleneck. Every method call to the entity bean is made via the network layer,
even if the caller is in the same address space as the called bean (that is, both the client, or
caller entity bean, and the called entity bean are in the same container). While some
container vendors optimize for this scenario, the developer cannot rely on this optimization
in all containers.
Additional chattiness can be observed between the client and the entity beans because
the client may have to communicate with many fine-grained entity beans to fulfill a
requirement. It is desirable to reduce the communication between or among entity beans
and to reduce the chattiness between the client and the entity bean layer.
Solution
Use Composite Entity to model, represent, and manage a set of interrelated persistent
objects rather than representing them as individual fine-grained entity beans. A Composite
Entity bean represents a graph of objects.
In order to understand this solution, let us first define what is meant by persistent
objects and discuss their relationships.
A persistent object is an object that is stored in some type of data store. Multiple
clients usually share persistent objects. Persistent objects can be classified into two types:
coarse-grained objects and dependent objects.
A coarse-grained object is self-sufficient. It has its own life cycle and manages its
relationships to other objects. Each coarse-grained object may reference or contain one or
more other objects. The coarse-grained object usually manages the lifecycles of these
objects. Hence, these objects are called dependent objects. A dependent object can be a
simple self-contained object or may in turn contain other dependent objects.
The life cycle of a dependent object is tightly coupled to the life cycle of the
coarse-grained object. A client may only indirectly access a dependent object through the
coarse-grained object. That is, dependent objects are not directly exposed to clients because
their parent (coarse-grained) object manages them. Dependent objects cannot exist by
themselves. Instead, they always need to have their coarse-grained (or parent) object to
justify their existence.
Typically, you can view the relationship between a coarse-grained object and its
dependent objects as a tree. The coarse-grained object is the root of the tree (the root node).
Each dependent object can be a standalone dependent object (a leaf node) that is a child of
the coarse-grained object. Or, the dependent object can have parent-child relationships with
other dependent objects, in which case it is considered a branch node.
A Composite Entity bean can represent a coarse-grained object and all its related
dependent objects. Aggregation combines interrelated persistent objects into a single entity
bean, thus drastically reducing the number of entity beans required by the application. This
leads to a highly coarse-grained entity bean that can better leverage the benefits of entity
beans than can fine-grained entity beans.
Without the Composite Entity approach, there is a tendency to view each
coarse-grained and dependent object as a separate entity bean, leading to a large number of
entity bean
- 浏览: 14455 次
- 性别:
- 来自: 北京
文章分类
最新评论
发表评论
-
集成层模式:Service Activator—服务激发器模式
2014-04-09 20:31 986ContextEnterprise beans and o ... -
集成层模式:Data Access Object—数据访问对象模式
2014-04-09 20:31 486ContextAccess to data varies ... -
业务层模式:Service Locator—服务定位器模式
2014-04-09 20:31 1129ContextService lookup and cre ... -
表示层模式:Value List Handler—值列表处理器模式
2014-04-09 20:32 734ContextThe client requires a ... -
表示层模式:Transfer Object Assembler—传输对象组装器模式
2014-04-10 22:48 721ContextIn a Java 2 Platform, ... -
业务层模式:Session Facade—会话门面模式
2014-04-08 21:38 399ContextEnterprise beans encap ... -
业务层模式:Transfer Object—传输对象模式
2014-04-08 21:37 395ContextApplication clients ne ... -
业务层模式:Business Delegate—业务委托模式
2014-04-08 21:37 950ContextA multi-tiered, distri ... -
表示层模式:Dispatcher View—分发者视图模式
2014-04-08 21:37 507ContextSystem controls flow o ... -
表示层模式:Service to Worker—工作者服务模式
2014-04-07 10:48 948ContextThe system controls flow ... -
表示层模式:Front Controller—前端控制器模式
2014-04-07 10:45 346ContextThe presentation-tier re ... -
表示层模式:Composite View—复合视图模式
2014-04-07 10:41 454ContextSophisticated Web page ... -
表示层模式:View Helper—视图助手模式
2014-04-07 10:37 993ContextThe system creates pre ... -
表示层模式:Intercepting Filter—拦截过滤器模式
2014-04-07 10:29 599Context The presentati ...
相关推荐
action层控制层 控制业务逻辑dao层 持久层 与数据库的交互service层(biz):业务层 控制业务domain层(entity):实体层
三层架够EntityFramework应用于DAL层 + 抽象工厂模式
Written by JuliaLerman, the leading independent authority on the framework,Programming Entity Framework covers it all -- from the Entity DataModel and Object Services to WCF Services, MVC Apps, and ...
组合实体模式(Composite Entity Pattern) 数据访问对象模式(Data Access Object Pattern) 前端控制器模式(Front Controller Pattern) 拦截过滤器模式(Intercepting Filter Pattern) 服务定位器模式(Service...
界面版MyBatis代码生成器,运行要求安装jdk1.8,自动生成entity、dao、service、serviceImpl、Mapper、Assist等。包含工具、文档、源码。
ADO.NET EntityFramework 实体完整版教程,从初级到中级,再到高级,循序渐进。
组合实体模式(Composite Entity Pattern)用在 EJB 持久化机制中。一个组合实体是一个 EJB 实体 bean,代表了对象的图解。当更新一个组合实体时,内部依赖对象 beans 会自动更新,因为它们是由 EJB 实体 bean 管理...
asp.net 3.5+entity framework实体框架三层实体一.
每当被观察实体之一更新时,它将更新,并从更改实体中获取last_seen / last_updated(可能还有GPS和电池)数据。 如果“输入”设备跟踪器的更新不定期,则结果可能是更准确和最新的设备跟踪器。 当前支持具有...
可以轻松应用于任何基于EntityFrameworkCore的实体框架数据库。 注意:该项目仅适用于单体项目,不适用于分布式应用,分布式应用请考虑使用大型的搜索引擎中间件做支撑,如:ElasticSearch | 项目开发模式:日常...
winewebsite:具有Entity Framework的.NET核心网站
grape-entity, 在对象模型的顶部,一个专注于 Grape::Entity 简介这里 gem 向API框架添加实体支持,如葡萄类。 葡萄实体是一个专注于对象模型之上的API的外观。示例module API module Entities cl
CapstoneShoppingList:使用Entity Framework和MVC从数据库下订单
Chapter 1: Introducing the ADO.NET 4.0 Entity Framework..................................1 Chapter 2: The Entity Data Model ........................................................13 Chapter 3: The ...
第5章 业务逻辑层:模式 5.1 应用设计模式 5.1.1 Factory Method模式 5.1.2 Decorator模式 5.1.3 Template Method模式 5.1.4 State模式 5.1.5 Strategy模式 5.2 应用企业模式 5.2.1 Specification模式 ...
FirstProject:具有EntityFrameWork核心的ASP.Net核心MVC
View Entity Data Model (Read-only) View Entity Data Model XML View Entity Data Model DDL SQL Generate Views When right-clicking on an Entity Data Model .edmx file, the following context menu ...
Cesium 中 实体类entity多种实例对象-实现点击事件
实体特征 活动 entity.isMovable = true // Required entity.x: Number entity.y: Number entity.xDirection: {LEFT, RIGHT, null} entity.yDirection: {UP, DOWN, null} entity.speed: Number // Set by server ...
ConEL:会话实体链接数据集该存储库提供与会话设置中的实体链接注释相关的资源。 这些资源是在现有数据集上创建的: (MWOZ) (QuAC), (WoW) 这些资源是在以下论文中开发的: Hideaki Joko, Faegheh Hasibi, ...