I wrote it one weekend to get ready for a project (packages are named org.apache.persistent.*); I can send you the original code with a sample Main if you are interested. I wrote it such that I could donate it to Jakarta possibly, but I'm not familiar with the procedures involved.
| -----Original Message----- | From: news [mailto:[EMAIL PROTECTED]] On Behalf Of V. Cekvenich | Sent: Friday, October 04, 2002 6:11 PM | To: [EMAIL PROTECTED] | Subject: Re: Persistence Framework Comparison? | | Is it free? Where can I "download" this? | Is there a sample? | | .V | | | Jacob Hookom wrote: | > I've always thought of a DAO not as an Adapter pattern as what you are | > describing, but as an external Table Gateway. BO interfaces and even | > the implementing classes shouldn't need to know how to persist itself or | > even what to persist to (XML, DB, IO). That is up to the implementing | > Gateway. | > | > I think a DAO should just extend the functionality of the business | > object, IE add configurable methods to persist, modify, select, etc and | > leave the actual O/R logic up to the database with views, triggers, and | > stored procedures (I wrote a book on this last time someone posted this | > same topic). | > | > Here's how our open source DAO works: | > | > Action.execute(ActionForm loginForm) | > { | > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance(); | > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml"); | > Method login = daoBroker.createMethod("login",User.class); | > | > try | > { | > conn = dataSource.getConnection(); | > User actual = (User) daoBroker.selectSingle(loginForm,user,conn); | > if (actual == null) throw new LoginException(); | > } | > finally | > { | > SQL.close(conn); | > } | > } | > | > The config for this DAO looks like: | > | > <class type="org.apache.persistent.junit.User" tableName="tbl_user"> | > <field name="email" column="email" pKey="true"/> | > <field name="password" column="password"/> | > <method name="login"> | > <sql> | > select * from tbl_user where email = ? and password = ? | > </sql> | > <input> | > <param name="email" idx="1"/> | > <param name="password" idx="2"/> | > </input> | > </method> | > </class> | > | > CRUD methods are automatically created at config time based on field | > definitions. It works great and the BO's are just left as retainers of | > state. If you need specialized operations like a persist only fields | > that are changed, then the <method> can take in a class of type Method. | > | > | > | -----Original Message----- | > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | > | Sent: Friday, October 04, 2002 5:33 PM | > | To: Struts Users Mailing List | > | Subject: Re: Persistence Framework Comparison? | > | | > | | > | | > | | > | | > | | > | >My wish was for a persistence or a ADO interface, and interface only, | > in | > | >Jakarta or else where respected. | > | > | > | >If there were such an interface one could switch from JDO to ORB to | > OJB | > | >to EJB to Simper to DAORowset to xyz, assuming other followed the | > | >interface. Let them compete. | > | > | > | >Such interfaces would have to be very light weight. (Ex: find(), | > save(), | > | >commit(), getProperty(""); setProperty("", Object)) | > | > | > | | > | | > | Asking for interfaces to be defined for ADO or a persistence layer | > seems | > | like asking for interface definitions for 'Model' components. | > | | > | I'd argue that the better approach is to create interfaces based on | > the | > | business requirements of your specific project. | > | | > | For example, define an Interface for a customer record and call it | > | 'Customer'. Then give it 'business methods' like 'getCustomerDetails' | > or | > | 'updateCustomerPhoneNumber'. Implement your Action class to act ONLY | > ON | > | THE INTERFACE METHODS. | > | | > | Then build 'Model' components that implement the Interfaces. This has | > the | > | effect of helping you keep code that is specific to a particular | > | persistance layer OUT of the Action class. Then when you need to | > switch | > | persistence layers from JDBC to EJB (or to a web service or whatever) | > your | > | ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED. | > | | > | For example: | > | | > | Customer cust = new CustomerJDBCImpl(); | > | | > | cust.updatePhoneNumber('1-800-IMA-NERD'); | > | | > | Where Customer is an interface and CustomerJDBCImpl is a class that | > | implements the Customer interface using a JDBC persistence layer. | > | | > | If you change persistence layers here, none of the code needs to | > change | > | in the Action class except you instantiate a different implementation | > | class. Since the Action class operates on the Interface methods, it | > | doesn't care. | > | | > | To summarize: | > | | > | - Leave persistence layer stuff out of Struts - it doesn't need | > it. | > | - Define your 'Model' components using Interfaces for each | > project | > | - Bury persistence layer stuff inside classes that implement | > | the interfaces. | > | - Then, make all the changes to your persistence layer you want | > | and your Action classes (and form beans, etc) don't change. | > | | > | This is the basic idea of MVC - seperate Model from View from | > Controller. | > | | > | | > | | > | I guess I think that one of the great strengths of Struts is ITS LACK | > | OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it | > | flexible and allows you to define Model components based on the | > 'business | > | rules' of the project - not based on what the framework recommends. | > | | > | Just my thoughts, for what they're worth - | > | | > | Kevin | > | | > | | > | ------------------- | > | Kevin Bedell | > | Author, "Struts Kickstart" - SAMS Publishing | > | | > | | > | | > | | > | | > | >>> | > | >>>Really? I think Struts is quite good at what it does, and to me, | > | >>>persistence seems to outside the scope of a web application MVC | > | >>>framework. | > | >> | > | >>Agreed. Struts does what it does best - web MVC framework. What the | > | >>original author of the comments (sorry, lost in my mailbox right | > now) is | > | >>looking for is what I would recommend happen on top of Struts. | > Something | > | >>that takes Struts, a proven OSS O/R framework, and some glue to make | > | >>DB-driven Struts applications faster to develop. | > | >> | > | | > | | > | | > | | > ------------------------------------------------------------------------ | > -- | > | - | > | This e-mail message (including attachments, if any) is intended for | > the | > | use | > | of the individual or entity to which it is addressed and may contain | > | information that is privileged, proprietary , confidential and exempt | > from | > | disclosure. If you are not the intended recipient, you are notified | > that | > | any dissemination, distribution or copying of this communication is | > | strictly prohibited. If you have received this communication in | > error, | > | please notify the sender and erase this e-mail message immediately. | > | | > ------------------------------------------------------------------------ | > -- | > | - | > | | > | | > | | > | -- | > | To unsubscribe, e-mail: <mailto:struts-user- | > | [EMAIL PROTECTED]> | > | For additional commands, e-mail: <mailto:struts-user- | > | [EMAIL PROTECTED]> | | | | | -- | To unsubscribe, e-mail: <mailto:struts-user- | [EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:struts-user- | [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
