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

Question

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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