Должен ли я создавать объекты картографирования или использовать декларативный синтаксис в SQLAlchemy?

Я обнаружил, что использование объектов сопоставления намного проще, чем декларативный синтаксис, если вы используете sqlalchemy-migrate для версии вашей схемы базы данных (и это обязательно для бизнес-приложение с моей точки зрения). Если вы используете объекты сопоставления, вы можете просто скопировать / вставить объявления таблиц в версии миграции и использовать простой API для изменения таблиц в базе данных. Декларативный синтаксис усложняет эту задачу, потому что вам нужно отфильтровать все вспомогательные функции из определений классов после их копирования в версию миграции.

Кроме того, мне кажется, что сложные отношения между таблицами более четко выражаются с помощью синтаксиса объектов сопоставления, но это может быть субъективным.

«Я не совсем уверен, какой подход более удобен в обслуживании для бизнес-приложений?»

В целом нельзя ответить.

Однако учтите это.

ORM Django является строго декларативным - и людям это нравится.

SQLAlchemy выполняет несколько вещей, не все из которых относятся ко всем проблемам.

1. SQLAlchemy создает специфичный для БД SQL из Python общего назначения. Если вы хотите возиться с SQL или сопоставить классы Python с существующими таблицами, тогда вам нужно использовать явные сопоставления, потому что ваше внимание сосредоточено на SQL, а не на бизнес-объектах и ​​ORM.

2. SQLAlchemy может использовать декларативный стиль ( как Django), чтобы создать все для вас. Если вы этого хотите, то вы отказываетесь от явного написания определений таблиц и явно возитесь с SQL. имеет хороший ctor, который принимает kwargs для всех полей. Полезно для тестирования и прочего. Например: user = User (name = 'doe', password = '42 ') . Так что не нужно писать ctor!

3. Если вы добавляете атрибут / столбец, вам нужно сделать это только один раз. «Не повторяйся» - хороший принцип.

Относительно «исключения ORM из бизнес-представления»: на самом деле ваш класс User , определенный «обычным» способом, серьезно исправлен. от SA, когда функция mapper справляется с этим. IMHO, декларативный способ более честен, потому что он кричит: «этот класс используется в сценариях ORM, и его нельзя рассматривать так же, как вы относитесь к своим простым объектам, не связанным с ORM».

doe ', пароль = '42') . Так что не нужно писать ctor!
4. Если вы добавляете атрибут / столбец, вам нужно сделать это только один раз. «Не повторяйся» - хороший принцип.

Относительно «исключения ORM из бизнес-представления»: на самом деле ваш класс User , определенный «обычным» способом, серьезно исправлен. от SA, когда функция mapper справляется с этим. IMHO, декларативный способ более честен, потому что он кричит: «этот класс используется в сценариях ORM, и его нельзя рассматривать так же, как вы относитесь к своим простым объектам, не связанным с ORM».

doe ', пароль = '42') . Так что не нужно писать ctor!
5. Если вы добавляете атрибут / столбец, вам нужно сделать это только один раз. «Не повторяйся» - хороший принцип.

Относительно «исключения ORM из бизнес-представления»: на самом деле ваш класс User , определенный «обычным» способом, серьезно исправлен. от SA, когда функция mapper справляется с этим. IMHO, декларативный способ более честен, потому что он кричит: «этот класс используется в сценариях ORM, и его нельзя рассматривать так же, как вы относитесь к своим простым объектам, не связанным с ORM».

"What I'm not completely sure, is which approach is more maintainable for a business application?"

Can't be answered in general.

However, consider this.

The Django ORM is strictly declarative -- and people like that.

SQLAlchemy does several things, not all of which are relevant to all problems.

1. SQLAlchemy creates DB-specific SQL from general purpose Python. If you want to mess with the SQL, or map Python classes to existing tables, then you have to use explicit mappings, because your focus is on the SQL, not the business objects and the ORM.

2. SQLAlchemy can use declarative style (like Django) to create everything for you. If you want this, then you are giving up explicitly writing table definitions and explicitly messing with the SQL.

3. Elixir is an alternative to save you having to look at SQL.

The fundamental question is "Do you want to see and touch the SQL?"

If you think that touching the SQL makes things more "maintainable", then you have to use explicit mappings.

If you think that concealing the SQL makes things more "maintainable", then you have to use declarative style.

• If you think Elixir might diverge from SQLAlchemy, or fail to live up to it's promise in some way, then don't use it.

• If you think Elixir will help you, then use it.