You can write portable code and still use any ND services you want. You
wall off the portable stuff from the non-portable code using interfaces.
I'm doing this now in ND4, plan to implement EJB in ND5.
Here's a simplified example:
package mystuff.portable;
//note do not allow any import statements for Spider classes
/**
* objects that implement this interface will perform insert, select,
update, delete on tables or other data stores or services
* arguments to all methods are vanilla java only.
*/
public interface PortableDataObject
{
/**
* Insert a new row
* @param Vector containing values to be inserted
* @return boolean true if insert succeeded
*/
public boolean insert(Vector values) throws Exception;
//similar for update, delete, select
}//public interface PortableDataObject
package mystuff.portable;
//note do not allow any import statements for Spider classes
public class PortableBusinessLogic
{
/**
* constructor
* @param classfactory supplies objects that implement the portable
interfaces. The objects might not be portable,
* but they will mostly be pass-throughs to vendor-supplied objects.
public PortableBusinessLogic(PortableClassFactory classfactory)
{
_classfactory = classfactory;
_log= classfactory.getPortableLog(); //when running under ND, classfactory
will return an object that calls CSpLog
//classfactory method takes table name as argument and returns an object
that implements portable interface.
_salarydataobject = _classfactory.getPortableDataObject("SalaryTable');
}//public PortableBusinessLogic(PortableClassFactory classfactory)
public boolean insertSalaryRow(String id, int salary) throws Exception
{
try
{
Vector buffer = new Vector();
buffer.addElement(id);
buffer.addElement(new Integer(salary));
return _salarydataobject.insert(buffer);
}//try
catch(Exception ex)
{
//can't use CSpLog -- would make code non-portable
_log.writeLog(this, PortableLog.ERROR, "insertSalaryRow, unexpected
Exception: " + ex);
throw (ex);
}//catch(Exception ex)
}//public boolean insertSalaryRow(String id, int salary) throws Exception
private PortableLog _log;
private PortableClassFactory _classfactory;
private PortableDataObject _salarydataobject;
}//public class PortableBusinessLogic
package mystuff.nonportable;
import mystuff.portable.*;
import spider.database.*;
import spider.*;
/**
* nonportable class implements portable interface using a NetDynamics
dataobject
* The data object must be of type CSpMultiSQL, and its name must be the
concatenation
* of "myDO" and the name of the table
*/
public class NDDataObject implements PortableDataObject
{
/**
* Constructor
* @param table Name of table
* @param classfactory Standard class factory, s/b an implementation that
supplies ND flavors of things.
*/
public NDDataObject (String table, PortableClassFactory classfactory)
{
_dataobject = (CSpMultiSQL) CSpider.getDataObject("myDO".concat(table));
//would check existence/class in real life
_classfactory = classfactory;
_log = classfactory.getPortableLog();
}//public NDDataObject (String table, PortableClassFactory classfactory)
/**
* Insert a new row
* @param Vector containing values to be inserted
* @return boolean true if insert succeeded
*/
public boolean insert(Vector values) throws Exception
{
try
{
//in real life we check size of buffer against number of columns in data
object
_dataobject.clearAllValues();
for (int i = 0; i<values.size(); i++)
{
Object columnvalue = values.elementAt(i);
//static utility method converts simple and compound Objects into
equivalent CSpValues
CSpValue columncspvalue = NonPortableUtility.getCSpValue(columnvalue);
_dataobject.setValue(i, columncspvalue);
}//catch (exception ex)
_dataobject.executeInsert();
return _dataobject.succeeded();
}//try
catch (exception ex)
{
//you could use plain old CSpLog, that's what it will always be under the
hood in a non-portable class running under ND
_log.writeLog(this, PortableLog.ERROR, "insert, unexpected Exception:" +ex);
throw (ex)
}//catch (exception ex)
}//public boolean insert(Vector values) throws Exception
//similar for update, delete, select
private PortableLog _log;
private PortableClassFactory _classfactory;
private CSpMultiSQL _dataobject;
}//public class NDDataObject implements PortableDataObject
Everything hinges on the class factory object supplying objects that
implement the services. In my current non-EJB implementation under ND,
each page instantiates a PortableClassFactory object of class
NDClassFactory. NDClassFactory supplies objects that implement the
portable interfaces by using various ND services. This object is passed to
the constructors of all objects created, portable or non-portable.
-- Curt Springer, Team ND
At 07:35 AM 4/21/99 -0800, [EMAIL PROTECTED] wrote:
>I may have answers to some of your questions.
>
>>How do we create PORTABLE beans accessing db and using ND db services ?
>>What would be the best option to develop a bean in ND (any bean other
than a container managed entity bean) that accesses
>>a database directly, but is still portable across different app server ?
>> Should I not use ND specific classes from spider.database.* package ?
Should I use java.sql.* package instead ?
>> But if I do, how about the db connection pooling management, that is
usually handled by ND app server ?
>>What services from ND would I miss by not using spipder.database.* classes.
>
>I am assuming you are using ND 5.0 which supports only session beans right
now (no entity beans).
>So your only option right now is to develop session beans that directly
use JDBC (java.sql.*).
>JDBC is the only way to access databases from EJBs if you want to take
advantage of container
>managed transactions (including two phase commits between different
databases). Moreover if
>you use spider.database.*, your bean woun't be portable across different
EJB servers.
>As fas as connection pooling is concerned, it can be handled by the JDBC
layer (JDBC 2.0 Standard
>Extention API with DataSource interface that does the connection pooling).
Any JDBC driver that
>supports 2.0 extentions (implements javax.sql.* interfaces) will do the
connection pooling for you.
>
>Hope this helps.
>
>
>
>
>[EMAIL PROTECTED] wrote:
>>How do we create PORTABLE beans accessing db and using ND db services ?
What would
> be the best option to develop a bean in ND (any bean other than a
container managed
> entity bean) that accesses a database directly, but is still portable
across different
> app server ? Should I not use ND specific classes from spider.database.*
package
> ? Should I use java.sql.* package instead ? But if I do, how about the db
connection
> pooling management, that is usually handled by ND app server ? What
services from
> ND would I miss by not using spipder.database.* classes. Can the ND
database services
> still be us
>_________________________________________________________________________
>
>For help in using, subscribing, and unsubscribing to the discussion
>forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
>
>For dire need help, email: [EMAIL PROTECTED]
>
_________________________________________________________________________
For help in using, subscribing, and unsubscribing to the discussion
forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
For dire need help, email: [EMAIL PROTECTED]
