Создание приложения WebForms в MVC 3 + Entity Framework

Question

У меня есть небольшое приложение, разработанное в ASP.NET 2.0 WebForms. В целях обучения я думаю преобразовать это приложение в MVC 3 + Entity Framework. Ниже приведен самый простой пример для моделирования моего приложения. Ничего особенного.

Форма приложения:

(изображение должно читать «поля ввода», а не «файлы»)

Архитектура:

Ключевые моменты:

1. Методы в слое Service используют метод ADO.NET SqlCommand ExecuteReader для выполнения хранимых процедур

2. Большая часть логики манипулирования и т. Д. Выполняется в хранимых процедурах. Вряд ли какие-либо манипуляции с данными в слое Service

Теперь я хочу преобразовать это приложение в MVC.

Вопросы:

1. Какую выгоду я получу (технически), если преобразовать это приложение в MVC + Entity Framework?

2. Как мне это сделать?

3. Я посмотрел некоторые базовые учебные пособия по MVC3, но все они рассказывают о коде EF в первую очередь, что, я не думаю, подойдет для моего случая, так как я хочу использовать существующие хранимые процедуры. Это правильно?

Примечание: Я хочу использовать существующие хранимые процедуры. Скажем, у меня нет контроля над изменениями структуры БД.

Обновление 1:

1. В моем приложении нет ни одного встроенного запроса. Даже самый маленький запрос - это хранимая процедура. Тонны из них.

2. Использование SQL Server и практически нулевые шансы перехода на любую другую DBS.

Обновление 2:

Мое приложение для веб-форм заполнено на 99% и может быть запущено в любое время, но из-за некоторых препятствий для бизнеса оно не имеет. В то время как я подумал, что если я смогу преобразовать (т.е. разработать) это в MVC, я узнаю, плюс, если он сработает, он может заработать (мой первый MVC) вместо веб-форм.

Answer 1

Какие преимущества вы получаете?Это совершенно неправильный вопрос.Вы должны спросить, какие у меня проблемы с текущим решением и как эти проблемы будут решены путем замены доступа к данным EF или замены уровня представления ASP.NET MVC?

Как я понимаю, вы хотите сделать это только для учебы - у нее нет бизнес-драйва.В этом случае есть несколько моментов, которые помогут вам получить некоторые идеи:

• Если вы не хотите заменять существующую логику SP общим способом EF, вы почти не получите никаких преимуществ и не будете учитьсяEF.EF позволяет использовать хранимые процедуры либо для извлечения сопоставленных объектов, либо для загрузки пользовательских классов.Сопоставленные сущности обычно представляют собой представления или таблицы из базы данных - здесь неясно, хотите ли вы даже определить какие-либо сопоставленные сущности.Единственное преимущество, которое вы получаете при загрузке пользовательских классов, - это автоматическое заполнение свойств из набора результатов.Это означает, что вам понадобится класс для каждого результата SP, свойства которого будут иметь имена, точно такие же, как столбцы в наборах результатов.SP в EF не поддерживает множественные наборы результатов (по умолчанию), а также не поддерживает автоматическую загрузку отношений.
• При переходе с веб-форм ASP.NET на ASP.NET MVC + Razor вы можете быть почтиубедитесь, что не ваш код переднего плана будет использоваться в новом решении.Вы просто создадите новый проект и создадите его с нуля.
• Как описано @marcind, эти два изменения полностью независимы - вы можете сделать одно без другого.

Answer 2

Прежде чем ответить на конкретные вопросы, я укажу, что вам, вероятно, следует разделить варианты на 2:

1. Преобразование уровня представления для использования MVC вместо WebForms.
2. Преобразование слоя данных для использования EF вместо ADO.NET.

Теперь на ваши вопросы

1. Преимущества MVC включают в себя улучшенный контроль над HTML, лучшую тестируемость и т. Д. Преимущества EF включают абстрагирование от специфических для БД вещей (теоретически можно заменить SQL Server на MySQL, при условии наличия соответствующего поставщика MySQL), поддержку LINQ и т. Д. Конечно, есть также затраты на такой переход.
2. Разделяй и властвуй. Как говорилось ранее, вам не нужно делать все сразу. Начните с уровня представления и преобразуйте его в MVC. Помните, что у вас могут быть смешанные приложения WebForms и MVC, поэтому вам не нужно перемещать все страницы одновременно. Затем преобразуйте слой данных в EF. Или начните в обратном порядке, что бы ни имело смысл для вашего проекта.
3. [Не эксперт в этой теме], если вы сильно полагаетесь на SP, а не на традиционные EF. Если у вас всего несколько SP, то вы могли бы сначала рассмотреть код + обработку SP с помощью DataSets (потенциально обернутых в пользовательские классы), чтобы все работало, хотя это может оказаться сложным. Как и раньше, вам не нужно переходить в EF, если цена слишком высока.