Основным вопросом при реализации ИС является выбор способа(механизма) доступа к данным.
 Вариантов множество: 
    1 самый примитивный: 
               на события объектов интерфейса привязанны вызовы запросов(SQL\SP) к БД, это неудобно неэффективно и т.д.
    2 в моих работах самый распространненый:
               создается отдельный класс доступа к данным, в котором и реализованы необходимые запросы к БД (SQL\SP), а в интерфейсе приложения происходит только вызов функций, которые возвращают набор данных.
    3 Современные способы такие как LINQ

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

 Сам разрабатываю с использованием VS2005+С#+SQL2005. 

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

Linq можно отнести как к 1му так и ко 2му способу. Реализацию все равно пишешь либо описывая отдельный класс, либо в обработчике методов элементов формы.
Я лично пользуюсь вторым (через класс) способом. 15 минут размышлений не навели меня на какие то революционные решения...
все стандартно. СУБД -> Провайдер -> Набор данных.

MasterOfCode


А как данные достаешь? 

SP, Queryes, LINQ?

Я достаю SP+ADO.NET, иногда мне кажется это громоздким, хочу перейти на SP+LINQ
Это позволит дополнительно работать с данными, полученными из базы. В смысле удобно работать  

Это сообщение отредактировал(а) archengel - 2.9.2008, 09:24

SP+LINQ. Хм... Я в последнее время участвовал в 3-х проектах с ORM, и, конечно, без хранимых процедур редко обходилось. Но хранимые процедуры создавались только для каких-то сложных операций, которые нельзя выполнить эффективно при помощи ORM. Если же переходить на ORM, но при этом продолжать писать хранимки под CRUD операции, особой разницы по сравнению с подходом ADO.NET + SP не почувствуешь.

Добавлено через 27 секунд
Под LINQ же имелся в виду LINQ To SQL?

Idsa 


угу



И как это реализуется, поделись если нетрудно.  

Что именно?

работа с ORM, я просто реально не понимаю как это работает. У меня тривиальных запросов 1запрос-1таблица по пальцам сосчитать, а сложных в которых участвует много таблиц уйма и я непонимаю как может осуществлятся SelectUpdateInsertDelete.......  

Это не есть сложный запрос (по крайней мере, я имел в виду несколько другое). С банальными join-запросами легко справится любая ORM. Под сложным запросом я имел в виду, например, прохождение дерева (имеется в виду реляционное представление дерева).


Материалов в сети много. Ничего экстраординарного в их работе нет. Да и до широкого распространения ORM в прогерских конторах зачастую создавались свои маленькие ORM (порой программисты просто не знали, что это так называется  ), дабы не писать однотипный ADO.NET код. Так что ничего нового в этом нет (тот же nHibernate (родной явовский, а не портированный под .NET) уже давно существует).
Единственное, что могу посоветовать, - начать изучение ни с Linq To Sql (про него вообще можете забыть), ни с nHibernate, а с EntityFramework: по возможностям он сопоставим с nHibernate, но сделан красивее, элегантнее и продуманнее (мое личное мнение).

SP, Querys + ADO.NET

Idsa, что такое ORM? прочитал в  Wiki слабо понял...

Как раньше проектировались базы данных? Сначала создаваль концептуальная модель, потом логическая, которая затем переводилась в физическую (по крайней мере в идеале все было именно так). Однако при написании объектно-ориентированных программ, работающих с реляционными базами данных программистам приходилось бороться с так называемым object-relational impedance mismatch. Кроме того, все это дело сопровождалось большим объемом рутинного кода. В итоге во многих конторах приходили к созданию своих фреймворчиков, которые отчасти решали вышеописанные проблемы.
Затем появилось целое направление так называемых ORM, которые решали те же проблемы, но были гораздо функциональнее, чем доморощенные ORM. ORM позволяют создать концептуальную модель на базе логической модели базы данных, используя разнообразный маппинг. Разные ORM поддерживают разные варианты маппинга, но возможность, например, наследования сущностей концептуальной модели (в реляционном подходе такого понятия, естественно, нет), не может не радовать. Кроме того, конечный Sql-код генерируется автоматически на основании манипуляции с сущностями концептуальной модели ORM, что избавляет программистов от написания рутинного T-Sql/PL-Sql и ADO.NET кода. Кстати, насчет манипуляций с сущностями. И EntityFramework (естественно), и nHibernate поддерживают LINQ, что делает ORM-запросы очень похожими на Sql-запросы. Писать их - одно удовольствие.
Я сам не так давно работал над проектом, в котором было ооочень много тривиального DAL'а, написанного по схеме SP + ADO.NET. Действительно много. Как представлю, сколько времени можно было бы сэкономить, используя ORM...

Это сообщение отредактировал(а) Idsa - 2.9.2008, 13:51

Вообщем нужно его (ORM) один раз увидеть, чтоб понять что это... Но уже сейчас немного догоняю что это удобная штука)

Да уж было бы здорово увидеть реальный проект изнутри. Чтобы понять. Теории много, буду пробовать....