-
Web Dynpro
是什么？
基于
MVC
设计模式的
SA
P Web Dynpro for JAVA
是在开发基于表单的用户界面中的具<
/p>
有革命性的意义。
它与
SAP
以往的设计范例完全不同，代表了开发基于
We
b
的
ERP Application
取得的重
大突破。
Web Dynpro
的双重目的：
>
尽可能避免对
UI
层进行编码；
>
允许业务应用程序以独立于后台业务平台，以及前端表现层的形式而存在。
为了开发用户界面，
Web Dyn
pro
提供了一个公布的元模型，这样就直接导致几乎无需编
写
程序代码。
Web Dynpro
与
其他
Web
开发工具的区别：
从开发者的角度而言，最基本的不同点在于：在其他开发工具
中（如
JSP
），是以
Web
页
作为开发单位，
而且您的应用程序由一套已经
被链接的页面组成，
这些页面共同提供所需要
的业务功能。
然而，在
Web Dynpro
中，是
以
“component”
为开发单位的，这里的
component
是指
一套相关的
Java
程序，
这些程序一起形成可重用的业务功能。
一个
component
可以没有
或者具有多个视图。从这一点上，
Web Dynpro comp
onent
可以认为是相关
Web
页的
聚合。
Web
Dynpro
应用程序的开发周期：
◆
分析阶段
◆
设计阶段
▲
架构设计
▲
详细设计
◆
实施阶段
在线资源：
Web Dynpro
for Java
（
SAP
公开）
/notes
（需要用户名
/
密码）
◆
分析阶段
在分析阶段，应确定并描述应用程序的业务需求。在这一阶段，仅需考虑是
“<
/p>
何种
”
业务
流程
，而不要考虑
“
如何
”
设计此流程。
此
阶段的成果物为分析模型，
使用非技术人员可以理解的语言完整准确、
< br>统一地描述业
务需求。
由于分析模型不考虑业务流程是
“
怎样
”
的，
所以此阶段进行的描述与任何特
定技术
（比
如
Web
Dynpro
）无关。
◆
架构设计阶段要解决的问题：
◎
为
Web
Dynpro
开发组件（
DCs
）建模
：
△
需要哪些开发组件来交付所需功能？
△
是否需要开发新的开发组件？是否可以重用现有开发组件？
△
要使用开发组件的哪些层次结构排列？
△
个开发组件之间存在哪些相关性？
△
哪些公共部分已发布？
◎
为
Web
Dynpro
项目建模：
△
Web
Dynpro
项目由哪些已经使用的
Web
Dynpro
组件组成？
△
哪些
Web
Dynpro
组件包含其他
Web
Dynpro
组件的接口视图？
△
Web
Dynpro
项目中使用哪些模型？
△
哪些
Web
Dynpro
组件使用哪一模型？
△
Web
Dynpro
项目中定义哪些
Web
Dynpro
组件接口？
△
哪些
Web
Dynpro
组件使用哪些
Web
Dynpro
组件接口？
△
各个
Web
Dynpro
组件之间存在哪些调用方法？各个
Web
Dynpro
组件之间使用
哪些结果？
△
Web
Dynpro
组件之间存在哪些上下文映射？
◆
详细设计阶段要解决的问题：
◎
为
Web
Dynpro
开发组件（
DCs
）建模
：
△
Web
Dynpro
组件由哪些视图组成？
△
Web
Dynpro
组件中使用哪些自定义控制器？
△
Web
Dynpro
组件内需要定义哪些方法和事件？
△
在
Web
Dynpro
组件内的哪些控制器中定义上下文元素？
△
在
Web
Dynpro
组件内定义上下文元素？
△
在
Web
Dynpro
组件内的哪些控制器中定义上下文元素？
△
绑定或者映射哪些上下文元素？
◎
为
Web
Dynpro
窗口建模：
△
应如何安排视图？
△
各视图之间存在哪些导航路径？
◎
为
Web
Dynpro
视图建模：
△
视图中包含哪些用户界面元素？
△
应如何安排视图的用户界面元素？
△
用户界面元素与哪些
Context
绑定？
△
用户界面元素绑定到哪些
Action
中？
一旦解决好上述问题，
就可以使用
NW
DS
中的图形窗口和组件建模工具开始构建应用程序
了。
SAP
建议的命名规范：
应用程序（
Application
）
=
{a}App
组件控制器（
Component
Controller
）
= {c}Comp
自定义控制器
(Customer controller)
={cc}Cust
组件接口视图
(Componet interface
view)
= {w}InterfaceView
任何类型的控制器
(A controller of any
type)
模型
(Model)
= {a}App
内向插件
(Inbound plug)
= {pi}In
外向插件
(Outbound plug)
= {po}Out
项目
(Project)
= {pr}
独立的组件接口
(Standalone
component interface)
独立的组件接口视图
(Standalone
component interface view)
组件使用（
Component
usage
）
= {p}Inst
视图（
View
）
= {v}View
视图集
(ViewSet)
=
{vs}Viewset
窗口
(Window)
独立
J2EE
引擎的第一个实例称为
JC00
。
JC
表示已安装
Java
引擎，
00
< br>则表示这是第一
个实体。
如果在同一计算机上已经安装了
独立
J2EE
引擎的另一实例，
则它的
实例标识通常
为
JC01
。
如果
J2EE
引擎作为
插件安装到
ABAP Web AS
中，
则实例标识可能类似于
DVEBMGS00
，
其中，每个字母表示已安装一个特定的流程类型。
00
则表示此计算机中的第一个实例。
，
设计时的上下文
< br>每个
controller
都有且只有一个具有层次结构
的数据存储结构，
这一结构就称为
Context
。
此
Context
所持有
的数据仅针对
controller
的
lifecycle
而存在。一旦终止
controller<
/p>
，
则其
Context
< br>所保存的所有数据均会丢失。
Context
是包含
node
与
at
tribute
的实体的层次结构安排。
上下文节点（
Node
）是主要的抽取类，用来将运行时的
数据存储在
WDF
内。
node
是数
据存储实体，
在此实体内，
系统会维护元素结合。
通常由缩写
{cn}
代表上下文节点，
{chn}
代表子节点。
属性（
att
ribute
）是上下文层次结构中的一个允许有子实体的实体。通常用
{ca}
代表。
为任何节点定义的子节点集形成一个单元，这个单元就称为
“
元素（
Element
）
”
二，
运行时的上下文结构
在上下文的运行
行为中，有两个特殊的节点属性起到关键作用，这两个属性分别为：
cardinali
ty
和
singleton.
基数（
cardinality
）属性
是由值对组成的，它控制运行包含的元素
{cn}
的最大数和最小数。
基数属性拥有以下四个可能值：
□
0 .. 1 : 0
或者
1
个
□ 0 ..
n : 0
或多个
□
1 .. 1 : 0
仅
1
个
□
1 .. n : 1
或多个
单
例
(Singleton)
属性
单例属性对子节点及父节点之间的关系有着至关重要的影响。
如果在设计时声明
{chn}
，那么根
据此节点是否为单例节点，为此节点而生成的接口将完
全不同。
参考：
/saphelp_erp2
005/helpdata/en/7a/787e40417c6d1de100
00
000a1550b0/
如果节点
的子节点设置为
Singleton
为
true
，则节点与子节点之间是一对多的关系。
反之，则是一对一的关系。
如下图所示：
上图可以看出，节点
SalesOr
ders
中的元素与每个
LineItems
< br>节点之间关系是
1
：
N
。
-
-
-
-
-
-
-
-
-
上一篇：包含红字的诗句
下一篇：新编实用英语(第二版)课后翻译