Модель на основе архитектуры хорошо работает с LINQ-to-SQL или Entity Framework?

Question

Моя недавно созданная система была создана с использованием подхода Model Driven Architecture, поэтому все, что у меня есть, - это модель (скажем, всеобъемлющие классы 'Order' и 'Product'). Это полностью протестированные классы, которые поддерживают бизнес моего приложения. Теперь пришло время сохранить эти классы как объекты на жестком диске и через некоторое время восстановить их в том же состоянии (думая очень абстрактно здесь). Обычно я создаю интерфейс IOrderRepository и, в конечном итоге, управляемый ADO.NET класс OrderRepository с такими методами, как GetAll (), GetById (), Save () и т. Д. ... или в какой-то момент управляемый BinaryFormatter класс OrderRepostiroy, который служит аналогичная цель через тот же общий интерфейс.

Является ли этот подход просто не подходящим для LINQ-To-Sql или Entity Framework. То, что пытается построить мою модель из уже существующей структуры БД, кажется неправильным. Могу ли я воспользоваться этими технологиями, но сохранить этот подход MDA к разработке программного обеспечения?

... заметьте, я не упомянул, что это веб-приложение. Это может или не может быть - и не должно иметь значения.

Answer 1

В общем, я думаю, что вы не должны создавать типы, реализующие бизнес-методы, и типы, используемые для отображения O / R, одного типа. Я думаю, что это нарушает принцип единственной ответственности. Смысл ваших типов сущностей состоит в том, чтобы преодолеть разрыв между реляционным пространством и пространством объектов. Смысл ваших бизнес-типов в том, чтобы иметь наборы тестируемого поведения. Вместо этого я хотел бы предложить вам проецировать из ваших типов сущностей на ваши типы бизнеса при материализации объектов из базы данных. Разделение этих двух элементов позволяет вашим бизнес-методам и сопоставлениям данных развиваться независимо, что очень важно, особенно если вы не всегда можете контролировать схему базы данных. Я объясню эту идею более полно в этой презентации .