views:

262

answers:

3

Hi,

What I really like about Entity framework is its drag and drop way of making up the whole model layer of your application. You select the tables, it joins them and you're done. If you update the database scheda, right click -> update and you're done again.

This seems to me miles ahead the competiting ORMs, like the mess of XML (n)Hibernate requires or the hard-to-update Django Models.

Without concentrating on the fact that maybe sometimes more control over the mapping process may be good, are there similar one-click (or one-command) solutions for other (mainly open source like python or php) programming languages or frameworks?

Thanks

+2  A: 

SQLAlchemy database reflection gets you half way there. You'll still have to declare your classes and relations between them. Actually you could easily autogenerate the classes too, but you'll still need to name the relations somehow so you might as well declare the classes manually.

The code to setup your database would look something like this:

from sqlalchemy import create_engine, MetaData
from sqlalchemy.ext.declarative import declarative_base

metadata = MetaData(create_engine(database_url), reflect=True)
Base = declarative_base(metadata)    

class Order(Base):
    __table__ = metadata.tables['orders']

class OrderLine(Base):
    __table__ = metadata.tables['orderlines']
    order = relation(Order, backref='lines')

In production code, you'd probably want to cache the reflected database metadata somehow. Like for instance pickle it to a file:

from cPickle import dump, load
import os

if os.path.exists('metadata.cache'):
    metadata = load(open('metadata.cache'))
    metadata.bind = create_engine(database_url)
else:
    metadata = MetaData(create_engine(database_url), reflect=True)
    dump(metadata, open('metadata.cache', 'w'))
Ants Aasma
+2  A: 

I do not like “drag and drop” create of data access code.

At first sight it seems easy, but then you make a change to the database and have to update the data access code. This is where it becomes hard, as you often have to redo what you have done before, or hand edit the code the drag/drop designer created. Often when you make a change to one field mapping with a drag/drop designer, the output file has unrelated lines changes, so you can not use your source code control system to confirm you have make the intended change (and not change anything else).

However having to create/edit xml configuring files is not nice every time you refractor your code or change your database schema you have to update the mapping file. It is also very hard to get started with mapping files and tracking down what looks like simple problem can take ages.

There are two other options:

Use a code generator like CodeSmith that comes with templates for many ORM systems. When (not if) you need to customize the output you can edit the template, but the simple case are taken care of for you. That ways you just rerun the code generator every time you change the database schema and get a repeatable result.

And/or use fluent interface (e.g Fluent NHibernate) to configure your ORM system, this avoids the need to the Xml config file and in most cases you can use naming conventions to link fields to columns etc. This will be harder to start with then a drag/drop designer but will pay of in the long term if you do match refactoring of the code or database.

Another option is to use a model that you generate both your database and code from. The “model” is your source code and is kept under version control. This is called “Model Driven Development” and can be great if you have lots of classes that have simpler patterns, as you only need to create the template for each pattern once.

Ian Ringrose
The EF designer is actually well thought out. You can run an update for the changes you have made in the database and it doesn't mess up the manual changes you have made to the schema/objects.
ADB
A: 

I have heard iBattis is good. A few companies fall back to iBattis when their programmer teams are not capable of understanding Hibernate (time issue).

Personally, I still like Linq2Sql. Yes, the first time someone needs to delete and redrag over a table seems like too much work, but it really is not. And the time that it doesn't update your class code when you save is really a pain, but you simply control-a your tables and drag them over again. Total remakes are very quick and painless. The classes it creates are extremely simple. You can even create multiple table entities if you like with SPs for CRUD.

Linking SPs to CRUD is similar to EF: You simply setup your SP with the same parameters as your table, then drag it over your table, and poof, it matches the data types.

A lot of people go out of their way to take IQueryable away from the repository, but you can limit what you link in linq2Sql, so IQueryable is not too bad.

Come to think of it, I wonder if there is a way to restrict the relations (and foreign keys).

Dr. Zim