Jon Scott Stevens <[EMAIL PROTECTED]> writes: > on 4/22/02 12:19 AM, "Leo Simons" <[EMAIL PROTECTED]> wrote: > >>> You also left out all the code related to getting the 'conn' >>> object. Torque >>> abstracts all that away so it isn't necessary at all. >> >> Which is not valid in every use case. CrossDB uses a factory. > > Huh? Not to grab the 'conn' object.
Leo, there is nothing which prevents use of application-supplied Connection objects with Torque. That said, it's annoying to _have_ to supply a Connection for every database access, so Torque hides that from the programmer in the usual case. >> You do not have to worry about typical O/R problems such as speed >> impediments. You can use crossDB in an interactive mode (like with >> BSH), while you cannot with Torque. > > Huh? I don't see why you can't use Torque with BSH. Indeed, nothing prevents such a use case. >> I could go on and on, but I see no point. Summary: >> >> Torque is a persistence layer that uses O/R mapping to use a database >> to provide persistence. A persistence layer is a handy tool in many >> server applications. >> >> CrossDB is a database abstraction layer that uses the Factory and the >> Builder pattern a lot which enables you to write code that works on >> several databases, transparantly. You can see it as an extension to >> JDBC. Database abstraction layers are useful in any application that >> talks to databases. I wouldn't mind seeing Torque use CrossDB under the covers instead of Village. It would be convenient to push the database abstraction down a layer. As it stands, Torque already abstracts a plethora of RDBMS implementaitons -- CrossDB would do well to use Torque as an example. > I'm sorry. I don't see that. Torque can do everything crossdb can do and > more. Jon is correct. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
