Уровень доступа к данным новичок

Question

Новичок в приложениях данных .NET здесь, из опыта Visual Foxpro.

Я планирую использовать ASP.NET и / или Silverlight UI, а также, возможно, некоторые клиентские приложения WPF для нашей локальной сети, поэтому я хочу создать слой доступа к данным, который может поддерживать все эти внешние интерфейсы.

Мои данные будут на сервере SQL. Я уже провел тестовый запуск передачи данных из Foxpro в SQL Server 2005. Все прошло хорошо. Это дало мне хранилище данных SQL-сервера для игры.

Теперь вот инструменты данных, с которыми я до сих пор играл, пытаясь ознакомиться с доступом к данным в .NET:

1. Я играл с Linq-To-Sql и создал тестовую форму, используя типизированные объекты и коллекции из L2S, а затем заполнил некоторые списки WPF и другие элементы управления пользовательского интерфейса. Это было круто. Линк это круто! WPF это круто. Смотрите скриншот формы здесь: http://twitpic.com/26w26/full

2. Я играл с тем, что, как мне кажется, вы бы назвали классическими ADO.Net DataSets. Человек, DataSets, похоже, много работы ... SQLConncetion SQLCommand Набор данных TableAdapter

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

Итак, позвольте мне спросить .... действительно ли сообщество разработчиков .NET работает с SQLCmds, DataSets и DataTables для чтения и записи данных? Это так работает?

Я знаю все об O / RM битвах там, и EF тоже.

Похоже, что вы можете подключить любой элемент управления пользовательского интерфейса из ASP.NET/Silverlight/WPF/ и WinForms к коллекции объектов (через OR / M) или DataSets / DataTables, верно? Это всегда выбор между одним из этих двух?

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

Answer 1

Прежде всего, единственный способ получить данные в SilverLight - через веб-сервисы WCF. Прямой доступ к базе данных в Silverlight запрещен (в конце концов, вы работаете в браузере)

Второе: (Я возьму это за флат). Наборы данных - зло. Прямое порождение дьявола. Избегайте любой ценой, если кто-то не держит пистолет к вашей голове. Первая проблема - это производительность: ее нет. Вторая проблема - потребление данных: 1k автоматически превращается в 3k. Не большая проблема для настольных приложений, но огромная для веб-приложений.

Третье: узнайте, что означает создание объекта домена. Оттуда вы можете использовать EF или NHibernate. Я предпочитаю NHibernate, но есть кривая обучения. Если у вас есть хороший объект домена, вы можете передать его любому клиенту, которого вы перечислили.

Answer 2

Я уже много лет пользуюсь старым классическим ADO.NET, и вы к нему просто привыкли. Для более крупного приложения вы можете потратить некоторое время на создание слоя данных, а затем повторно использовать его со многими другими бизнес-объектами.

Пара других опций:

1. Сильно типизированные наборы данных. Вы можете создать строго типизированный набор данных, который позволит вам перетаскивать объекты базы данных и сгенерирует много кода для вас.

2 linq To Sql designer, который также позволяет перетаскивать объекты в конструктор и генерирует dbml-файл, который вы используете для подключения и манипулирования вашими данными.

Я недавно попал в подножку Linq, и это упрощает вашу жизнь при обработке данных как объектов.

Удачи!

Answer 3

Люди, которые используют наборы данных, фактически используют IDE для создания строго типизированных наборов данных.

Используя это, вы получаете визуальный построитель запросов, похожий на построитель запросов SQL Management Studio. Это генерирует функцию для загрузки / сохранения и т. Д. С параметрами.

Тот факт, что вы видите наборы данных повсюду, во многом связан с тем фактом, что это было единственное решение, доступное до сих пор, за исключением ручного кодирования SQL везде.

В наши дни ORM все в моде, и они обеспечивают действительно хороший уровень абстракции.

Answer 4

В ADO.NET "Classic" (API DataSet / DataTable API) нет ничего плохого, и по крайней мере в одном случае я решил использовать его, а не ORM. Тем не менее, тот факт, что ADO.NET «Классик» чаще используется, во многом является историческим артефактом. В течение долгого времени это был единственный жизнеспособный вариант, особенно если вы хотели использовать решение только для Microsoft.