Модель для ASP.NET MVC

Question

Я только начал с ASP.NET MVC 1.0. Я прочитал несколько уроков, но у меня нет хороших идей о том, как построить мою модель.

Я экспериментировал с LINQ to SQL. Не могу сказать, что мне это очень нравится, но я попробую. Я предпочитаю использовать хранимые процедуры SQL, но, похоже, он не очень хорошо работает с дополнительными параметрами в моих хранимых процедурах.

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

База данных, вероятно, будет содержать около 50 таблиц, и хранимые процедуры будут использоваться для всех запросов и обновлений. Некоторые процедуры также будут возвращать несколько результатов. Как бы наилучшим образом спроектировать эту модель?

Все и любые идеи приветствуются. Должен ли я даже использовать LINQ to SQL? Должен ли я разработать свои хранимые процедуры так, чтобы они возвращали только один результат? Я чувствую себя немного потерянным.

Answer 1

Вы можете использовать хранимые процедуры с LINQ. Вам просто нужно заменить автоматически сгенерированные операторы ваших сущностей сохраненными вами процессами. Посмотрите на свойства объекта (таблицы) в конструкторе, чтобы изменить их. Ваши хранимые процедуры не смогут возвращать несколько результатов, поскольку они должны отображаться в коллекцию одной из ваших сущностей или автоматически сгенерированной сущности, т.е. в коллекцию одного класса.

Сказав все это, я бы попробовал без использования хранимых процедур. Код LINQ полностью параметризован, поэтому у вас уже есть это преимущество. Вы обнаружите, что LINQ позволяет вам легко создавать запросы, облегчая вашу потребность в необязательных параметрах в ваших хранимых процессах и, вероятно, приводя к более эффективным запросам, поскольку вам не нужно встраивать дополнительную логику в запрос для обработки необязательных параметры. Когда вы начнете использовать LINQ, я думаю, вы обнаружите, что мощь и выразительность кода заставят вас забыть об использовании хранимых процедур.

Возможно, вам все еще понадобятся хранимые процедуры или табличные функции для сложных запросов - это нормально. Если они отображаются на существующую сущность, вы можете просто перетащить proc / function на сущность в конструкторе, и вы получите хороший метод в вашем контексте данных, который запускает ваш SQL и возвращает коллекции этой сущности. Если нет, я часто создаю представление для схемы proc / function, использую его как сущность и присоединяю к нему proc / function.

Answer 2

Могу я спросить, зачем вам использовать хранимые процедуры для этого проекта? Они почти не имеют значения сегодня, если вы работаете с современной базой данных. Параметризованный SQL с использованием хорошего ORM даст вам те же кэшированные планы выполнения и преимущества безопасности, которые вы ищете с помощью хранимых процедур.

Я бы порекомендовал NHibernate , потому что это гораздо лучший способ добиться постоянного невежества. И ИМХО, это цель любого, кто разрабатывает модель. Сначала вы должны думать об объекте, а не о данных.

Лучший ресурс вокруг - это скринкаст Стив Болен" Лето nhibernate "

Также LINQ to NHibernate доступен и отлично работает для любого динамического запроса, который вам может потребоваться написать.

Единственная боль, которую вы заметите в NHibernate, - это XML, но если вам действительно нравится ORM, вы можете написать свободный интерфейс вместо использования FNH .

Я обнаружил, что NHibernate является лучшим инструментом для моделирования домена, потому что ваши объекты на 100% свободны от инфраструктуры, и это позволяет вам делать с ними все, что угодно, не беспокоясь о базе данных. Кроме того, если вы участвуете в модульном тестировании любого рода, это значительно облегчит вашу жизнь: P

Редактировать

Одна из причин, по которой я ответил на ваш вопрос, заключается в том, что я построил много систем с использованием хранимых процедур и позже обнаружил, что сожалею об этом решении. Но в моей ситуации у меня было требование к дба, поэтому я не мог отойти от нормы.

Если вы уже рассматриваете LINQ to SQL, я бы просто рекомендовал вам взглянуть на NHibernate как на еще один отличный вариант для достижения цели постоянного невежества.

Когда я впервые задумался о проблемных данных, это позволило мне работать на более высоком уровне и использовать платформу .net для решения проблем. TSQL имеет свое место, но если вы пишете приложение и хотите его поддерживать - попробуйте сначала подумать о том, как ваши доменные объекты будут работать вместе в памяти.

Редактировать 2

Не уверен, почему я получил отрицательный голос за предложение NHibernate - в конце концов, вы сказали, что вы открыты для чего-то другого, кроме L2S

«Все идеи приветствуются. Должен ли я даже использовать LINQ to SQL? Должен ли я создавать свои хранимые процедуры так, чтобы они возвращали только один результат? Я чувствую себя немного потерянным».

Смысл моего ответа был именно в этом - дать еще одну "долгожданную" идею ...