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

StackOverflow https://stackoverflow.com/questions/201132

  •  03-07-2019
  •  | 
  •  

Вопрос

Я буду вести урок, и мне нужно объяснить, какие факторы должны повлиять на ваше решение о технологии доступа к данным.Я знаком со многими методами доступа к данным, такими как типизированные наборы данных, Linq to SQL, Linq to Entities, .netTiers, LLBLGen, а также пользовательские вызовы с объектами подключения SQL и объектами команд.Некоторые из моих клиентов разрешают использовать только хранимые процедуры и НЕ обсуждают ничего другого.Некоторые из моих клиентов еще НЕ готовы установить .NET 3.5.Некоторым клиентам требуется средний уровень веб-служб в любом веб-приложении.Большую часть времени я использую наборы данных Types и пользовательские веб-службы или использую .netTiers с CodeSmith.О чем еще мне следует думать?

Это было полезно?

Решение

Как и все варианты в программном проекте:Это зависит...Но, на мой взгляд, самым важным фактором является среда проекта.

Он состоит из (в любом случае я не претендую на полноту этого списка):

  • Доступные навыки в команде разработчиков И команде сопровождения (если они разные)
  • Требуемые функции
  • Ограничения, установленные клиентами (не все клиенты поддерживают все доступные технологии).Это, безусловно, следует учитывать при постепенной замене устаревшей системы или внедрении новой системы в среду).
  • Ограничения, установленные законодательством

надеюсь, это вам поможет.

Другие советы

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

Важно учитывать:

  • ETL/Нагрузки/Миграция
  • Внешняя интеграция/синхронизация (BizTalk/SSIS)
  • Повторное использование другими приложениями (особенно веб-сайтами, мобильными приложениями и т. д.)
  • Безопасность/поверхность атаки (является ли один подход менее безопасным, чем другой?)
  • Задачи обслуживания
  • Доступность – будет ли база данных использоваться круглосуточно?Обеспечит ли один подход лучшую доступность, чем другой, и т. д.
  • Кроме того, необходимо учитывать некоторые дизайнерские соображения.Вы настраиваетесь на более быстрый выбор или более быструю запись?Одна схема доступа к данным может работать лучше, чем другая.

    Я не утверждаю, что существует одна серебряная пуля, но я предупреждаю, что любой шаблон проектирования доступа к данным требует обдумывания «общей картины»: решит ли он сегодняшние проблемы и то, что вы можете разумно предсказать, может стать потребностями завтрашнего дня?

    Кроме того, будете ли вы предоставлять внешний API или какую-то структуру для согласованного доступа к данным?Будет ли это раскрыто прямо или косвенно?

    Я думаю, что есть место как для Entity Framework/LINQ to SQL, так и для традиционных хранимых процедур и других инструментов, таких как NHibernate (и т. д.), но вам следует сначала обосновать и рационализировать выбор технологии и попытаться убедиться, что она подходит для настоящие и будущие потребности.

    РЕДАКТИРОВАТЬ:Извините, я забыл самое важное:ремонтопригодность.Некоторые решения на основе шаблонов предлагают вам приличные преимущества в возможности восстановления DAL после изменений схемы по сравнению с другими (например, написанными вручную хранимыми процедурами).Стоит сопоставить преимущества производительности с недостатками.

    Я думаю, что между вашим исходным сообщением и дополнениями norbertB вы осветили практически все.Начните с абсолютных ограничений (и помните: если клиент однажды сказал «нет» чему-то – даже если он говорит, что это абсолютно – это не значит, что вы не можете помочь ему изменить свое мнение…).После того, как вы сузили поле с помощью абсолютных ограничений, обратите внимание на другие вещи.

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

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

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

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top