Schema Value Object (转)[@more@]Schema Value Author Olivier Brand (obrand@ .com) 08/23/2001 Context Value Objects must include validation code in order to optimize work traffic and features for B2B s. Problems While implementing a three tier application using Core Patterns, a usual design will involve at least some Value Objects, some Session Facades, a few Entity Beans and Data Access Objects for the underlying persistence logic. A Value Object is the representation of a business data. Therefore it contains attributes and associated business methods. A Value Object can be initialized by the Enterprise Bean layer (in the case of reads) or by the Client (in the case of creations or updates). Usually the Value Object does not need to be validated when being created in the Enterprise layer since we assume that the data has already been constrained by the persistent store. A problem occurs when creating or updating these Value Objects (mutable Value Objects) in the Client layer. For instance an attribute representing the e address of a customer in the Value Object can be tied to a specific column in a database with additional constraints such as the length of the column and its format following a specific pattern (regular expression driven, ...). Now the developer needs to make a decision where to add the validation code on this field. The most common solution is to rely on the underlying datastore which will reject the insert or update if a field does not confo to a specific constraint. The problem of relying on the datastore to check the data constraints is expensive in term of network overhead. Another problem is that the implementation is more complex since the eventual thrown exceptions need to traverse multiple layers and be interpreted by the client layer. B2B data exchange must be realized through the HTTP protocol to overcome restrictions. Standards such as P, eBxml, ... are already defined. Multiple implementations of these standards allow to wrap Enterprise Beans in a Service. Since the Enterprise Bean layer plays the role of a Value Object Factory, the reulting data needs to be tran ormed at one point as XML to be encapsulated into SOAP or eBxml packets. Forces  The validation of a Value Object is done early on, avoiding Network overheads (similar to the role of for form validation in web  applications)  Simplify the three tier layer in term of exception handling  Can rely on specifications such as XML Schemas (or DTDs) for documenting and generating (see solution) data constraints.  XML aware Value Objects can be easily included in B2B exchanges Solution Use an existing XML to express data constraints and automate the process to unmarshal XML documents to Java Objects and to marshal Java Objects to XML documents. There are many XML frameworks available. Some are relying on DTDs, others are relying on the newest XML Schema (aka XSD) specifications. I chose to rely on the XML Schema specification in order to express the Value Object constraints.XML Schemas are defined in XML (as opposed to DTDs), therefore can be created using any XML aware tools, documentation can also be generated using transforms (output HTML, ....). XML Schemas are "object oriented friendly" since they allow for complex types creation and extension. The framework of choice used for implementing this pattern is Castor from Exolab. This framework is on its way to support the final W3C specification, but it showed in any projects that its Schema support is enough for implementing this pattern. This framework is also . The main a is to write an XML schema corresponding to the structure of the final Value Object (in term of attributes and types), and add the constraints as defined in the database (length, format, .....). Some constraints such as uniqueness cannot be expressed, but typically, you want the underlying database to reject the record if such constraint is violated. Then you can use the Castor source generator class to generate the Java classes associated with the XSD Schema. Each complex type is sually defined as a Class. Each element, attributes are defined as properties (class variable) and corresponding setter/getter methods are automatically generated. Relying on a source generator prevents coding complex validation rules in a language that cannot be understand by non Java developers. For instance a Database modeler and an Architect (or Senior Developer) can be involved early on in order to define those schemas. This will be the starting point for the DDL and the Schema Value Objects generations. This is a nice approach to bring 2 different teams together on a design and implementation phases. Then the Schema Value Objects need to be created. At this stage there are 2 possible choices:  The Schema Value Object extends the generated Java class from the XSD schema.  The Schema Value Object encapsulates (wraps) the generated Java class from the XSD schema. I prefer the second solution for 2 reasons:  The Castor framework (or any other Schema aware framework generators) defines new types which correspond to the richer XSD Schema definition  (compared to Java types). Therefore, you might want to hide these "proprietary" classes allowing later on (if needed) to replace the Java Schema  generator with another one (for instance, when Javasoft will provide a Schema module for its JAXB framework).  You might want to validate field by field (when each setter is being called) and add some dirty flag support in the same methods. Wrap the  generated setters with your own setters make then more sense. When generating the Java classes from the XSD Schema using Castor, special classes called Descriptors are created. These classes are handling the validation part (the constraints defined in the XML Schema are showing in this classes). Do we want to validate field by field or the entire document ? Once again this is an implementationd ecision mostly driven by the client's implementation. In my implementations, we decided to validate field by field (the validation is done in each setters). To perform a field level validation, the Castor XML offers a class to perform validation at the field level (as opposed as the entire document):  FieldValidator. I highly encourage you to look at castor.exolab.org in order to get familiar with the possibility of the product. The second part of the pattern is trivial since any Schema (or DTDs) aware code generator, Castor included, include marshaling and unmarshaling facilities. These methods allow to transform Java to XML and XML to Java. Castor offers 2 classes to perform such transformations: Marshaller and Unmarshaller. The Marshaller class can transform a Java object to XML. Some methods allow to marshal the object directly in a W3X Node object. This method is highly optimized when dealing with SOAP where you want to include a fragment (therefore the generated Node) in a SOAP enveloppe. This method is also preffered when dealing with XSL (in frameworks like Cocoon, ....) since the DOM tree is already built. This method also works with the W3C SAX API. The Unmarshaller class can transform any XML sources to the Castor generated Java object. One of my projects included this pattern and was successfully implemented using the Apache SOAP framework with a WSDL extension we had to write. WSDL is an XML document containing the definition of the operations exposed as web services. Any complex types are referred to an XML Schema. This is one of the reason why this pattern perfectly applies to B2B exchanges by bringing the J2EE and B2B worlds together. Consequences  Takes advantage of the Value Object pattern  Therefore it reduces network traffic.  Uses W3C standards to express data constraints  Schemas or DTDs can be understood by non java developper and is the common ground for B2B exchanges (see WSDL, SOAP, UDDI, ...)  Allows for automated code generation  Once the XSD Schema written, a Java Binding framework like Castor, can be used to generate the Java classes.  Includes an XML framework to serialize/deserialize Java object to and from XML.  This fits perfectly in the Web Services world. This can also be used in Web Applications driven by s and XSLT processing. Related patterns  Value Object (Sun)   (GoF) Links  SUN patterns: http://developer.java.sun.com/developer/restricted/patterns  GoF Patterns: http://www.hillside.net/patterns/DPBook/DPBook.html  Castor XML: http://castor.exolab.org 2 replies in this thread Schema Value Object Posted By: Olivier Brand on August 25, 2001 in response to . This pattern could (and should) be renamed: Schema Data Object. This approach applies to a lot of scenari and schemas are a good complement to add constraints to languages. The Value Object could be one implementation of this pattern. 0 replies in this thread Schema Value Object - Options Posted By: Earl Bingham on August 31, 2001 in response to . At sourceforge.net there is a project called jvalid that was started last year that does validation with XML Schemas. http://sourceforge.net/projects/jvalid/ Also, there is a XSLT Stylesheet called Schematron that is designed to allow validation of XML Documents to be done with a definition of the validation in XML. http://www.ascc.net/xml/resource/schematron/schematron.html I have started a project in sourceforge.net to build some J2EE components that can be re-used that leverage the Schematron Stylesheet.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10748419/viewspace-998409/，如需转载，请注明出处，否则将追究法律责任。