What's your favourite way of interacting with databases from your programming language? [closed]
There are numerous ways to connect and interact with the database layer. In Java, for example, common usages are JDBC calls of raw SQL, object relational mappers, JDBCTemplate (Spring), stored procedures, etc.
In your language, which option is your preference and why? When would you consider the others?
I really like the 3 + 1 tier way of doing things. One tier for UI, one for business logic, and for persisting data. The last one you say? Domain objects and interfaces. This makes it possible to load up any one or two of the main tiers plus the domain "tier", and the code should work.
It relies heavily on dependency injection and Inversion of Control principles. The data/persistence tier does only two things. It creates, reads, updates and deletes data, and maps it to the domain object format.
The UI tier does the exact opposite. It displays and receives data in a way that the user can relate to, and maps that output/input to and from the domain object format.
The business logic tier just need to know one thing. Business logic. It does not care about where the data is from, and it does not care about where the data tier is putting it. It knows that it should flag an account that was just overdrawn, how to physically do that is not part of its job really.
The domain objects themselves does not have any logic, they are just containers for passing data between the tiers. This means that you can load the domain objects and interfaces without having to think at all about dependencies.
At the end of the day I feel that I have a pretty clear code base with clearly separated tiers. And with some strict interfaces and good base classes most of the coding is just telling the software what to do when X happens. Just how it is supposed to be.
Edit: Oh, yeah. This is true for both the LINQ, SubSonic, and other ORMs.
LINQ is the way to go for me from here on
I prefer to build a business object model layer (objects and collecitons of objects).
I build the ability to interact with the database into each object/collection (for SQL Server, I use System.Data.SqlClient). I've used this pattern for SQL Server, MySQL and Oracle.
Then I interact with the objects from my application code.
By abstracting my database into objects, my application code is consistent regardless of the backend database.
ORM is indeed fantastic.
I use SQL Alchemy when working within python - it works with just about every DBMS I've run across.
For lightweight data-driven applications on MacOS X, I use Core Data, which has a great data modelling tool accessible via Xcode.
Both of these show that ORM done right is excellent. I've had less success and enjoyment with EJB.
I haven't gotten into the LINQ world yet, but I've really come to love the DataTable/TableAdapter classes that Visual Studio has done by means of an XSD dataset. By means of a few drags and clicks after creating my database schema, I now have a DataSet/DataTable object that is strongly typed and I have adapter methods that are using parametrized queries to my stored procedures for all my CRUD statements. It'll even create query table adapters for some of those procedures that aren't directly tied to a table.
Oh, and if you haven't created the stored procedures yet and just have the tables, the wizard will create the procedures or the adhoc SQL statements for you.
This has been out since Visual Studio 2005 and has drastically cut down on my "structure" time with my new web apps and I can focus more on the business and presentation logic.
We use a mixed approach, depending on what will suit for the particular situation within the application:
- When reading a page worth of information to display and for a user to update we use Hibernate
- When processing a batch of updates or summarizing where most of the data is already in the database (e.g. end of day processing) we use PL/SQL (and try to think in sets)
- When a user performs a search or runs a summary report, we use ibatis sqlmaps to build up some SQL and bring back only the fields we are interested in (not every column and certainly not any unnecessary child rows, urggh)
- Anything that really has to run quick, we'll use whatever approach works best
This is with java/Oracle.
ActiveRecord, which is a pattern documented first (I think) in Fowler's Patterns of Enterprise Architecture. I believe it's implemented in languages other than Ruby, although it's well-known as a core technology in Rails. Whatever, it's a neat abstraction of the database, although I have to confess that I find it a bit clunky and in the find_by_sql area. But that may just be me.
But (putting on Grumpy Old Man hat now) all the ORMs in the world are no substitute for a good knowledge of SQL, without which I really don't like to see access to an RDBMS being permitted at all.
We use Delphi and Oracle Data Access Components (ODAC) and ADO via Oracle.OleDBProvider.
May favorite way is to use Smalltalk with a GemStone Object Repository. Why? No ORM problem to deal with. I would only consider something else if forced or threatened by my employer.
My favourite way is to have an object abstraction layer. Ideally, this is only place that works with SQL. But in practice, the objects sometimes need to do SQL-y things, too. But nothing outside the object.
So far, I've written such layers myself because what was available was too awkward, too slow or too big.
I use plain JDBC because I'm developing a data-driven application and my database model is very complex. Everything is described in the database, even structure of other tables. In addition to this I use stored procedures a lot. Therefore ORM is not an option for me.
We are currently using ODAC to talk to the Oracle database and use a lot of Oracle Packages (PL/SQL). The n-tier system is done through RemObjects which means our client has no SQL in it whatsoever and only needs the ability to send HTTP requests so no installation overhead.
All this is done using Borland Delphi and has been woking for 2 years in a production environment.