如何在XPage中实现适当的层分离(即与Java对象交谈,而不是与Domin
|
我正在尝试在我的XPage项目中实现适当的图层分离.理想情况下,我试图达到XPage中的
XML不包含SSJS并仅使用EL来访问
Java对象的程度.
到目前为止,我已经研究了如何将我的所有数据从domino数据库加载到Java Beans(其中1个文档= 1个对象,或多或少),我正在将视图内容读入Java Maps或Lists,并且我已经管理过在重复控件中显示这些集合的内容. 我不确定的是如何在不引用多米诺骨牌文档的情况下显示单个文档的“表单”的内容.特别是,我不确定如何处理“新文件”案件.我想我创建了一个空对象,然后将该对象设置为Xpage的数据源. 我知道我必须使用ObjectDataSource,但我不确定在哪里存储它.我读了Stephan Wissel的一篇文章,说不应该把它们放在托管bean中,那么我在哪里可以把它放进去？在像viewScope这样的范围变量中？ 现在我写了一个’ApplicationBean’,它是一个会话范围的Managed Bean,我存储了所有的对象. 什么是最佳做法？似乎有许多不同的方法来实现这一目标.目前我正在探索ChristianGüdemann的XPages工具包,这听起来非常有前途.我知道Samir Pipalia,John Daalsgard和Frank van der Linden已经制定了自己的框架. 那我该怎么办呢？任何陷阱？ 解决方法
这确实是一个很大的话题.正如Paul所提到的,Tim的文档模型类是如何清楚地做到这一点的一个很好的例子,Tim在NotesIn9系列的后续剧集中详细介绍了.我自己的Framework的模型对象非常相似,但我还添加了
collection managers来处理访问视图的脏业务.无论好坏,几乎每个XPage开发人员都以独特的方式解决了这个问题.
有许多方法可以实现这种方法,在正常情况下,一些差异并不是非常重要(例如,在构造模型对象时是否预加载文档中的所有数据或进行延迟提取只在需要的时候到后端),但肯定有几个需要解决的首要问题. 模型访问 正如您在问题中提到的,其中一个重大问题是您如何从XPage实际访问模型对象 – 如何从数据库中提取对象或重新创建对象. My Framework的模型对象使用“Manager”对象的自负,这些对象是应用程序范围的bean,允许获取命名集合(映射到视图),UNID模型对象或通过关键字“new”获取新模型对象.通常,这些模型(可序列化)然后通过< xp：dataContext />,< xe：objectData />或者框架自己的< ff：modelObjectData存储在页面的视图范围中. /取代. 我发现避免使用托管bean来表示单个对象(比如“CurrentWhatever”,然后用每个页面上的数据填充)是非常明智的,因为在最好的情况下会弄乱你的faces-config或者遇到会话问题.最糟糕的(如果你把它放在会话范围内,我很少使用). 你如何实现“新”与“获取”的模型对象在很大程度上取决于你首先编写模型所采取的策略,但大多数归结为有两个构造函数：一个采用UNID(至少)指向现有文件和一个创建新文件.如果你去“使用getter和setter明确地在对象中写入”路由,后者也会使用默认值初始化所有字段,而不是从文档中读取它们.在内部,您应该有字段来存储文档的UNID,这可以指示它是否是新的 – 然后,您的save方法可以检查此字段是否为空并在需要时创建新文档(然后存储新文档的UNID)在该领域). 查看 听起来你已经将你的模型集合读入Lists了,这很好.但是,其中一个缺点是可扩展性：如果集合量较小(少于100个),则可能不会遇到任何加载速度问题,但随后在代码读入时,初始页面加载速度会变慢整个视图提前.您可以使用efficient view reading缓解这一点,但是有一个限制.内置视图通常很快,因为它们只根据需要加载数据(他们也像地狱一样作弊,但这是另一个问题). 这是一个以自己为目标的崇高目标,但这样做是为了涵盖所有案例是no small feat：你最终遇到了FT搜索,列求助,高效数据预加载的问题(你不想只重新打开View对象)一次读入一个条目,但您也不想阅读整个内容),在viewPanel和其他(需要专门的接口),扩展/折叠类别等中使用.这是large sub-topic on its own. 秘籍 您还可能会遇到比您最初想象的更困难的其他区域,例如“正确”的富文本处理和文件附件.特别是,附件需要direct conflict with the XSP framework才能使用自定义模型对象和标准上载/下载控件正常运行. 字段名称中的区分大小写是另一个潜在的麻烦区域.如果您正在为所有字段编写getter和setter,那么这是一个没有实际意义的问题,但如果您要使用“瘦包装”路径(我更喜欢),那么以一种方式对任何中间缓存/查找进行编码非常重要.处理“FOO”和“foo”(基本上)与Notes的项目名称相同的事实,但在Java中是不同的.我采取的方法是制作extensive use of 让你的模型对象与所有标准控件一起工作,这可能是也可能不是优先考虑 – 我发现它非常有价值,所以我做了大量的工作来实现我的框架,但是如果你要做的话一些基本的字符串和数字模型,你不一定需要担心. 所以…是的,这是一个很大的话题！根据您对Java和XPage undergirding的信心,我建议或者为您的对象选择相当简单的“带有getter和setter的bean”的路线,或者查看现有框架之一的实现细节(我自己的)或你提到的那些).遗憾的是,随着代码变得越来越复杂,有许多小问题会出现,其中很多都是不明显的. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |