Как я могу расширить модель в ASP.NET MVC и Entity Framework?

В моих первых приложениях ASP.NET MVC модель представляла собой простое сопоставление O / R между таблицей и классами, управляемое Entity Framework.

Теперь я хотел бы добавить немного мяса к этому каркасу и представить бизнес-методы для сгенерированных классов. Каков рекомендуемый подход к этому в ASP.NET MVC (с Entity Framework)? Мне больше всего нравится решение, которое также можно использовать на уровне службы без ссылок на ASP.NET MVC, чтобы та же логика домена также могла быть повторно использована в настольном клиенте.

Технически я думаю, что должна быть возможность расширить сгенерированные классы таким образом, чтобы сохранить дополнительную бизнес-логику, даже если классы O / R необходимо обновить. (Однако это больше вопрос, связанный с Entity Framework.)

Изменить: большое спасибо за вклад и информацию о следующей версии Entity Framework (4.0). Создание двух наборов классов, один автоматически сгенерированный для представления данных на уровне постоянства, а другой - для реальной бизнес-логики, звучит интересно.


model entity-framework asp.net-mvc business-logic
person mjn    schedule 19.08.2009    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Если вы используете EF v1.0 прямо сейчас, Entity Framework очень навязчиво влияет на ваше приложение, а это означает, что вы не можете легко создать POCO. Вы можете расширить свою модель, используя частичный класс. Поэтому, когда вы обновите свою модель, созданный вами частичный класс будет по-прежнему действителен. Команда Entity Framework понимает, что это проблема, и улучшила ее в следующей версии (EF V4.0).

NHibernate гораздо удобнее и позволяет легко расширять бизнес-логику.

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

person J.W.    schedule 19.08.2009

arrow_upward
4
arrow_downward

В MVC.Net модель - наименее четко определенная часть. На мой взгляд, это в основном остальная часть вашего приложения (т.е. все, что не связано с представлением или контроллером). Часть вашего приложения, отображающая O / R, вероятно, также должна находиться за пределами «Модели», так как это скорее уровень данных. Модель действительно должна иметь дело с бизнес-объектами и создавать представления ваших данных для передачи в View.

По этому поводу существует множество различных мнений, но я думаю, что лучше не думать о MVC.Net как о традиционной архитектуре MVC.

person Jimmeh    schedule 19.08.2009
comment
Правильно ли я понимаю, что вы предлагаете создать бизнес-логику с использованием отдельной иерархии «бизнес-объектов», которые затем сопоставляются с «объектами данных», предоставляемыми структурой O / R? - person mjn; 19.08.2009
comment
Это способ сделать это. Я думаю, есть много способов. Я действительно думаю, что уровень сопоставления O / R должен быть отделен от бизнес-логики. - person Jimmeh; 19.08.2009
comment
+1. Хотя вы можете расширять сгенерированные типы сущностей, гораздо лучше сохранить вашу бизнес-логику полностью независимой от EF, а затем проецировать результаты запроса сущности на типы BL через LINQ. - person Craig Stuntz; 19.08.2009
comment
Ограничение EF v1.0 на POCO является здесь проблемой, и она будет решена в следующей версии v4.0. - person J.W.; 19.08.2009
comment
J.W., я полностью не согласен. Никакие POCO не являются ограничением, если вы должны втиснуть свою бизнес-логику в сущности. Если вы сделаете свою бизнес-логику полностью отдельной, как предлагает Джимме, тогда вы можете спроецировать свои сущности на бизнес-объекты с помощью LINQ. BO - это настоящие POCO, а не прокси-базы, 100% участников которых объявлены общедоступными виртуальными. - person Craig Stuntz; 19.08.2009
comment
Крейг, я понимаю и согласен с твоей точкой зрения. Если я правильно понимаю, вы хотите создать еще один слой BO поверх этих классов сущностей, созданных Entity Framework. Для меня это будет более понятный подход, если я смогу получить POCO прямо из структуры сущностей, поэтому мне не нужно использовать другой уровень. - person J.W.; 20.08.2009
comment
Да, J.W., верно. Использование отдельного бизнес-уровня - это разделение задач. Ваша модель сущности отображает реляционные данные в объектное пространство; ваши БО - это логика вашего приложения. Средний слой позволяет им развиваться независимо. Однако ORM со сломанными / ограниченными / несуществующими реализациями LINQ вынуждены использовать POCO. - person Craig Stuntz; 20.08.2009
comment
Крейг, я не уверен: если бизнес-уровень отделен от уровня сохраняемости, бизнес-уровень должен также отслеживать манипуляции с объектами (единицы работы), а затем передавать эти изменения на уровень сохраняемости, который затем выполняет те же операции для применения изменений к БД. Я понимаю, что у развязки есть преимущества, но какова цена на нее? - person mjn; 07.11.2009

arrow_upward
1
arrow_downward

Преобразуйте свой бизнес-уровень в другой проект, а затем передайте его экземпляр в контроллер mvc, используя что-то вроде карты структуры. Затем вы можете вызвать этот бизнес-уровень со своего контроллера, чтобы получить свои бизнес-объекты (модель) и передать их пользовательскому интерфейсу. Это позволит вам повторно использовать бизнес-уровень в настольном приложении.

person StarSignLeo    schedule 19.08.2009

arrow_upward
0
arrow_downward

В этот проект можно добавить не только мясо, но и одежду и стиль, чтобы он выглядел шикарно. Это зависит от времени, которое у вас есть на проект. Если у вас есть время, я могу предложить вам взглянуть на TDD и фреймворки, которые можно использовать с TDD, такие как Castle, NUnit, Moq и т. Д.

Как вы упомянули, уровень обслуживания является обязательным для любого проекта, но с такими фреймворками вы можете разработать свою архитектуру более надежной.

person Ali Ersöz    schedule 19.08.2009