Reply content:
The Django model driver pays little attention to the implementation details at the database level, and the process of defining the models is very close to declarative rather than procedural, which may be the reason for the new project to make Django model more pleasing than SQLAlchemy.
The traditional use of SQLAlchemy is not to invade the model, in a separate place to define the table structure, mapping rules, and then injected into the model class with SQLAlchemy driver, this method can completely avoid the model and database coupling, but the definition of cumbersome, require developers fully understand the engine, Metadata, table, column, Mapper and other concepts, if not read "Enterprise Application architecture Model" a class of books will be confused.
Now SQLAlchemy provides a way to declarative, much like the Django model, but still has a certain distance from the declarative models, with little loss of flexibility. But I compared the Django model with the SQLAlchemy declarative and found that the Django model was more concise. For example, for a class association, Django automatically produces the associated object if it directly declares the foreign key, and sqlalcyhemy to define the foreign key, relationship object, and if there are multiple foreign keys to specify the join rule yourself ... In short, flexibility is a good thing, but not under any circumstances pleasing to the people.
I was going to say that this is ActiveRecord style and Data Mapper style differences, but think about it, Django Model is not a simple ActiveRecord, it is very adaptable to complex associations and even inherited mappings. Should be the same type as the SQLAlchemy declarative, which is the Active Record style wrapper for Data Mapper. SQLAlchemy use on two levels, 1 is the use of SQL expression, white can let you write SQL with Python, 2 is its ORM, ORM is to use the session, self-management session lifetime, self in a number of processes pass session , manage the transaction yourself. The notation is the usual transaction script (the "domain model" of the anemia that Java often says). The actual encoding is usually 1 and 2 mixed programming.
Django hides the concept of connection/transaction management through middleware, and is simpler to approach, close to Java's often-said, congested domain model. There is also no sqlalchemy SQL expression hierarchy on the content. Ease of use is reflected.
However, the use of the ORM, can reach sqlalchemy such a high level of ORM, has not been seen in other languages. Ruby has sequal, and Java's jooq have some sqlalchemy of thought because it's an ORM in the Django World. What are the most important features of Django? Quickly generate a background management interface from ORM! There is also the concept of modelform, data Migration (migration) and so forth from the Django Orm ... If you choose SQLAlchemy, then it's all gone, you have to build it yourself, or use a third-party library. Say, without built-in ORM, no built-in admin interface, no built-in modelform, no data migration, Django, or Django? It's better to use a lighter or looser frame directly!
In addition, it is not reliable to use Django Orm alone outside of Django. If it is a different environment, it would be nice to use SQLAlchemy. I have been translating SQLAlchemy, Django, sqlobject documents since 2006. You can see the English document yourself, SQLAlchemy. Is that for people to see? An ORM just, got 1000 pages of documentation, and the word was particularly dense, nonsense a basket of baskets. I suspect that the person writing the document is in some classical Chinese writing in English, simple words, but almost all kinds of synonymous words, strange grammar.
An inverse of the English document can refer to Flask's documentation, which is called a simple and understandable one.
In 2006-2007, I completed the documentation for Sqlobject and SQLAlchemy in turn (partial translation). The sqlobject was found to be declining (many people have not heard of it). And SQLAlchemy is such a wonderful existence. I had to take care of the dbutils and then stop using any ORM.
In my opinion, ORM is a package on top of SQL, and this package introduces a package that is too thick, so that the programmer's control of the underlying is significantly weakened, and too many new designs are added. So I do not agree with the use of ORM, or clean SQL is much more useful. The ORM diagram is simple and convenient, Django's ORM happens to meet this demand, complex directly with the native SQL can be the Django ORM when independent come out ah ....
