Блог

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

Макет приложения:

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

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

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

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

2. Большая часть манипуляций и т.д. логика выполняется в хранимых процедурах. Практически никаких манипуляций с данными на уровне сервиса

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

Вопросы:

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

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

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

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

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

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

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

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

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

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

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

Теперь по вашим вопросам

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

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

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

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