#asp.net #sql #linq-to-sql #stored-procedures
#asp.net #sql #linq-to-sql #хранимые процедуры
Вопрос:
Мы — небольшая команда, работающая в очень сжатые сроки над разработкой большого веб-приложения в .NET. Мы используем несколько баз данных (по одной на клиента), поэтому наши требования немного отличаются от требований большинства приложений. Базы данных будут использоваться только для этого конкретного приложения, поэтому не имеет значения, тесно ли они связаны с приложением. Основными решающими факторами являются скорость разработки, долгосрочная ремонтопригодность и безопасность. Мы рассматриваем 3 варианта:
Вариант 1 — LINQ to SQL
Ни у кого из нас нет опыта работы с LINQ, но мы изучали его, и он кажется хорошим вариантом и не слишком сложным в освоении. Стоит ли рисковать, изучая новый метод в сжатые сроки?
Вариант 2 — Хранимые процедуры
Похоже, что поддерживать настройку с несколькими базами данных может быть кошмаром (или будет?), И это может замедлить разработку для работы в другой среде, поскольку у нас нет специального разработчика базы данных. Базовые CRUD-запросы будут генерироваться генератором кода, что является преимуществом.
Вариант 3 — Встроенные запросы
Этот метод был бы самым быстрым в разработке, но я знаю, что в настоящее время люди, как правило, против жестко запрограммированных запросов, и я боюсь, что в долгосрочной перспективе мы можем пострадать из-за проблем с ремонтопригодностью. Базовые CRUD-запросы будут генерироваться генератором кода.
Пожалуйста, дайте мне знать, если есть какие-либо факторы, которые мы упускаем. Какое решение кажется наиболее подходящим для этого проекта?
Комментарии:
1. насколько велик «большой» и насколько плотно «плотно»? Я спрашиваю, потому что изучение Linq2SQL не сложно и, вероятно, увеличит ваше время до завершения, если вы говорите о более чем неделе или двух. Но если значение large является «достаточно большим», вы, скорее всего, столкнетесь с одной или двумя слабостями в нем, и вам все равно понадобится что-то еще.
2. Крайний срок составляет 3-4 месяца, и проект не является невероятно сложным или масштабным, просто большим по сравнению с нашими прошлыми проектами и размером нашей команды. Вероятно, будет 30-40 таблиц.
3. Хотя это очень сложно сказать, поскольку я понятия не имею о вашем домене, но с NoSQL вы, скорее всего, могли бы смоделировать все свое хранилище данных, вероятно, в 10 ~ 15 совокупных корнях. Возможно, даже меньше. В текущем приложении, которое я создаю с помощью RavenDB, у нас есть 1 основной совокупный корень и 2 вспомогательных, которые больше предназначены для исторических целей.
Ответ №1:
Если у вас сжатые сроки, не пробуйте что-то новое. Попросите разработчиков изучить Entity Framework дома и в свободное время и попробовать его в следующем проекте. Тем временем делайте то, что вы знаете лучше всего и успешно использовали в прошлом.
Встроенные запросы неплохи, если они разделены в сборке DAL.
Комментарии:
1. Согласитесь с этим, и я рекомендую взглянуть на Dapper, который позволяет вам писать встроенные запросы с меньшими затратами. ado.net шаблонный шаблон
Ответ №2:
Поскольку @Hasan Khan рассмотрел основные ответы, касающиеся SQL. Я собираюсь дать несколько иной ответ. Другой вариант — рассмотреть возможность использования RavenDB, базы данных NoSQL. В нем заложена концепция клиентских баз данных. Что из ваших требований звучит так, как будто это намеченная цель.