Типичная архитектура .NET DDD против практики Django / Rails

Question

Я привык ко всем типичным методам проектирования на основе предметной области, которые распространены в большинстве публикаций и блогов, посвященных современному программированию .net. Поэтому меня удивило, что, когда я разговаривал с некоторыми людьми из Django, они не заботились о невежестве упорства, моделях представления и т. Д.

Недостаток неосведомленности о персистентности может показаться понятным, когда вы используете Active Record в Django или Rails, но неверительное использование доменных сущностей в представлениях выглядит как чистое зло после того, как немного поработал в ASP.NET MVC land (то же самое с Java mvc frameworks, я думаю).

Это не единственный случай, это относится к подавляющему большинству проектов Django / Rails (которые всегда воспринимались как Uberagile).

Почему это? Это просто из-за особенностей динамического языка, которые делают ненужными такие практики, как DI? Или, может быть, в корпоративном мире .NET / Java есть слишком много опыта?

Знаете ли вы еще какие-либо архитектурные различия? Есть ли какие-то уроки для мира .net / java или, наоборот, просто Rubist и Pythonistas обычно не работают с достаточно большими проектами, чтобы понять преимущества этих шаблонов?

Answer 1

Хорошо, много обсуждений уже. Вот мое мнение по этому вопросу:

Обычно гораздо проще получить доступ к модели домена непосредственно для ваших форм. Это одна из тех вещей, которые дают кодирование в Rails (я не знаю Django, но я предполагаю, что это то же самое), огромное повышение производительности. Вряд ли есть какая-либо потребность в кодировании: создайте таблицу базы данных, создайте немного html и простой контроллер в середине, и все готово. Поскольку в коде практически нет кода, его можно изменить быстрее, поэтому он хорошо работает в Agile-средах.

Но есть время, когда этого не хватает. Иногда ваше приложение слишком сложное, чтобы заставить его работать должным образом. Именно тогда вы можете добавить ViewModels, Presenters, Facades или как вы хотите их называть. Ничто не мешает вам делать это в Rails или Django. Фактически, Rails 3 представил ActiveModel в виде набора миксинов, чтобы каждый объект работал с формами так же просто, как и при работе с ActiveRecord.

Таким образом, вопрос не в том, почему Rails и Django не делают этого, а когда я должен это использовать? Называть DDD переобработкой тоже не соответствует действительности. Речь идет о «достаточно», чтобы решить проблему, которая у вас есть. Сохраняйте минимальный объем кода и сложность, и вам будет проще поддерживать его.

Я бы согласился с тем, что, безусловно, есть уроки, которые можно извлечь из Java / .NET. Обычно они хорошо разработали шаблон дизайна. Но говорить, что Rubyists и Pythonistas не сделали достаточно больших проектов, неверно. Сила приходит в понимании, когда вы можете сойти с простого решения.

Я думаю, что Java-программисты (у меня нет опыта работы с .NET-программистами) имеют тенденцию к чрезмерному совершенствованию. Может быть, это фреймворки, которые они используют. Кажется, он пытается заставить программиста сделать это «Правильным путем», что делает его слишком сложным.

Answer 2

Возможно, это ваша возможность объяснить преимущества модели представления, поскольку я лично считаю ее пустой тратой времени и пространства. Хотя большая часть моей работы с MVC была в Rails, в настоящее время я работаю в Spring и до сих пор всегда напрямую взаимодействовал с моделями, хранящимися в моей реляционной базе данных.

Если вы намереваетесь сделать некоторые атрибуты модели недоступными, не раскрывайте их. Вы можете предоставить им дополнительную защиту в своем методе before_save или в другом месте, если хотите, но действительно ли это необходимо, учитывая вероятность того, что пользователь знает имена атрибутов, которые вы выбрали не раскрывать?

Если есть и другие причины, по которым модель представления выгодна, тогда я весь в ушах (или в глазах, в зависимости от обстоятельств).