Building Model Components

原创 2004年11月02日 15:48:00

2. Building Model Components

2.1 Overview


Many requirements documents used for building web applications focus on the View. However, you should ensure that the
processing required for each submitted request is also clearly defined from the Model's perspective. In general, the developer of the Model components will be focusing on the creation of JavaBeans classes that support all of the functional requirements. The precise nature of the beans required by a particular application will vary widely depending on those requirements, but they can generally be classified into several categories discussed below. However, a brief review of the concept of "scope" as it relates to beans and JSP is useful first.

2.2 JavaBeans and Scope

Within a web-based application, JavaBeans can be stored in (and accessed from) a number of different collections of "attributes". Each collection has different rules for the lifetime of that collection, and the visibility of the beans stored there. Together, the rules defining lifetime and visibility are called the scope of those beans. The JavaServer Pages (JSP) Specification defines scope choices using the following terms (with the equivalent servlet API concept defined in parentheses):

  • page - Beans that are visible within a single JSP page, for the lifetime of the current request. (Local variables of the service method)
  • request - Beans that are visible within a single JSP page, as well as to any page or servlet that is included in this page, or forwarded to by this page. (Request attributes)
  • session - Beans that are visible to all JSP pages and servlets that participate in a particular user session, across one or more requests. (Session attributes)
  • application - Beans that are visible to all JSP pages and servlets that are part of a web application. (Servlet context attributes)

It is important to remember that JSP pages and servlets in the same web application share the same sets of bean collections. For example, a bean stored as a request attribute in a servlet like this:

MyCart mycart = new MyCart(...);
request.setAttribute("cart", mycart);

is immediately visible to a JSP page which this servlet forwards to, using a standard action tag like this:

<jsp:useBean id="cart" scope="request"

2.3 ActionForm Beans

Note: While ActionForm beans often have properties that correspond to properties in your Model beans, the form beans themselves should be considered a Controller component. As such, they are able to transfer data between the Model and View layers.

The Struts framework generally assumes that you have defined an ActionForm bean (that is, a Java class extending the ActionForm class) for the input forms in your application. ActionForm beans are sometimes just called "form beans". These may be finely-grained objects, so that there is one bean for each form, or coarsely-grained so that one bean serves several forms, or even an entire application.

If you declare such beans in your Struts configuration file (see " Building the Controller Components"), the Struts controller servlet will automatically perform the following services for you, before invoking the appropriate Action method:

  • Check for an instance of a bean of the appropriate class, under the appropriate key, in the appropriate scope (request or session).
  • If there is no such bean instance available, a new one is automatically created and added to the appropriate scope (request or session).
  • For every request parameter whose name corresponds to the name of a property in the bean, the corresponding setter method will be called. This operates in a manner similar to the standard JSP action <jsp:setProperty> when you use the asterisk wildcard to select all properties.
  • The updated ActionForm bean will be passed to the execute method of an Action class [org.apache.struts.Action], so that the values can be made available to your system state and business logic beans.

For more about coding Actions and ActionForm beans, see the "Building Controller Components" chapter.

You should note that a "form", in the sense discussed here, does not necessarily correspond to a single JSP page in the user interface. It is common in many applications to have a "form" (from the user's perspective) that extends over multiple pages. Think, for example, of the wizard style user interface that is commonly used when installing new applications. Struts encourages you to define a single ActionForm bean that contains properties for all of the fields, no matter which page the field is actually displayed on. Likewise, the various pages of the same form should all be submitted to the same Action Class. If you follow these suggestions, the page designers can rearrange the fields among the various pages, often without requiring changes to the processing logic.

Smaller applications may only need a single ActionForm to service all of its input forms. Others applications might use a single ActionForm for each major subsystem of the application. Some teams might prefer to have a separate ActionForm class for each distinct input form or workflow. How many or how few ActionForms to use is entirely up to you. The framework doesn't care.

2.4 System State Beans

The actual state of a system is normally represented as a set of one or more JavaBeans classes, whose properties define the current state. A shopping cart system, for example, will include a bean that represents the cart being maintained for each individual shopper, and will (among other things) include the set of items that the shopper has currently selected for purchase. Separately, the system will also include different beans for the user's profile information (including their credit card and ship-to addresses), as well as the catalog of available items and their current inventory levels.

For small scale systems, or for state information that need not be kept for a long period of time, a set of system state beans may contain all the knowledge that the system ever has of these particular details. Or, as is often the case, the system state beans will represent information that is stored permanently in some external database (such as a CustomerBean object that corresponds to a particular row in the CUSTOMERS table), and are created or removed from the server's memory as needed. Entity Enterprise JavaBeans are also used for this purpose in large scale applications.

2.5 Business Logic Beans

You should encapsulate the functional logic of your application as method calls on JavaBeans designed for this purpose. These methods may be part of the same classes used for the system state beans, or they may be in separate classes dedicated to performing the logic. In the latter case, you will usually need to pass the system state beans to be manipulated to these methods as arguments.

For maximum code re-use, business logic beans should be designed and implemented so that they do not know they are being executed in a web application environment. If you find yourself having to import a javax.servlet.* class in your bean, you are tying this business logic to the web application environment. Consider rearranging things so that your Action classes (part of the Controller role, as described below) translate all required information from the HTTP request being processed into property setter calls on your business logic beans, after which a call to an execute method can be made. Such a business logic class can be reused in environments other than the web application for which they were initially constructed.

Depending on the complexity and scope of your application, business logic beans might be ordinary JavaBeans that interact with system state beans passed as arguments, or ordinary JavaBeans that access a database using JDBC calls. For larger applications, these beans will often be stateful or stateless Enterprise JavaBeans (EJBs) instead.

For more about using a database with your application, see the Accessing a Database HowTo.

解决myeclipse保存总是出现:cteating aop reference model markers的问题

解决办法:window--->preferences--->Validation--->Spring--->Project Builder--->AOP Reference Model Builder...
  • editcue
  • editcue
  • 2012年09月03日 17:55
  • 1175

Eclipse保存Spring配置文件xml时显示Building Spring AOP reference model错误框的关闭方法

运行环境:集成了Spring IDE的Eclipse An internal error occurred during: "Building Spring AOP reference model"....
  • z28126308
  • z28126308
  • 2016年11月17日 13:46
  • 2460


安装配置略 setting.xml文件使用默认 示例程序 1 新建hello-world文件夹   2 在该文件夹中创建pom.xml文件  1 ...
  • retacn_yue
  • retacn_yue
  • 2014年08月27日 14:31
  • 6601


处理下面的警告需要 [WARNING] Some problems were encountered while building the effective model for
  • u013008179
  • u013008179
  • 2016年03月19日 00:00
  • 5381


错误原因: 编译下载最新的maven源代码,但是出现错误。错误如下: [WARNING] Some problems were encountered while building the...
  • thisisvoa
  • thisisvoa
  • 2013年08月23日 15:35
  • 5037

Designing ActiveX Components with the MFC Document/View Model

W hether youre an experienced Win32® guru or a junior Windows® wanna-be, you...
  • l12345678
  • l12345678
  • 2007年07月27日 14:56
  • 7115

building Spring aop reference model has encountered a problem

最近  myeclipse  项目一直在报这个错,很烦,一保存就保存,项目还能正常启动,但就是不知道问什么报这个错。 我的第一个解决方案是删除工作空间下的一个配置文件,这个是在网上百度来的,造成的结果...
  • u011293970
  • u011293970
  • 2017年12月28日 11:07
  • 16

An internal error occurred during: "Building UI model". com/google/common/base/Function

An internal error occurred during: "Building UI model". com/google/common/base/FunctionEclipse Neon....
  • testcs_dn
  • testcs_dn
  • 2017年12月14日 09:31
  • 461

Building components in MXML

 Building components in MXMLIn typical Adobe® Flex™ applications, you do not code the entire applica...
  • Anglewing_nwpu
  • Anglewing_nwpu
  • 2007年06月23日 00:32
  • 791

Building Custom Components

Android offers a sophisticated and powerful componentized model for building your UI, based on the f...
  • jackie_gnu
  • jackie_gnu
  • 2011年07月11日 15:36
  • 249
您举报文章:Building Model Components