Консолидированное обсуждение: LinqDataSource или ObjectDataSource?

У меня есть веб-приложение среднего размера с серверной базой данных на базе SQL Server.

Обзор моей БД - Общие предложения для SQL 2005 Framework \ Дизайн и реализация

Обзор инфраструктуры моего приложения - L2S (LINQ to SQL) или EF (Entity Framework) )

Итак, пока мы находимся в ускоренном развитии. Мы «заморозили» миграцию на архитектуру MVC и, чтобы сделать ее проще / быстрее, мы выбрали LINQ-to-SQL вместо Entity-Framework (также учитывая тот факт, что через несколько месяцев появится улучшенная Entity Framework v2.0) . Надеюсь, это правильно.

Теперь, когда я вернулся к старому коду - в прошлом мы использовали ODS (objectDataSource) во всех местах для операций поиска и CRUD. Итак, стоит ли заменить его новым LinqDataSource (LDS).

Я только что нашел одно полезное сообщение о stackoverflow: SqlDataSource vs ObjectDataSource

Я сослался на многие учебники СПД. Отличная серия, которую я создал на CodeProject:

Part1: http://www.codeproject.com/KB/aspnet/LinqDataSourcebasics.aspx
Part2: http://www.codeproject.com/KB/aspnet/LinqDataSourcebasics1.aspx
Part3: http://www.codeproject.com/KB/aspnet/LinqDataSource2.aspx
Part4: http://www.codeproject.com/KB/aspnet/LinqDataSource3.aspx

Я также посетил несколько дискуссий по «сравнению», например - (Хорошее) http://www.eggheadcafe.com/aspnet/how-to/146339/linqdatasource-vs-objectd.aspx

Знаменитая серия из 5 частей ScouttGU о LINQ - http://weblogs.asp.net/scottgu/archive/2007/07/16/linq-to-sql-part-5-binding-ui-using-the-asp-linqdatasource-control.aspx

Я не могу углубляться - мне нужно знать, что по этому поводу говорят эксперты. Я склонен к использованию ODS, поскольку он обеспечивает лучшую абстракцию (в отличие от (почти) двухуровневого LDS). И для будущей миграции MVC это также поможет лучше структурировать приложение.

Другая ссылка: http://www.dotnetspider.com/forum/165941-What-Difference-between-ObjectDataSource.aspx


.net sql-server objectdatasource linqdatasource
person Hemant Tank    schedule 24.11.2009    source источник
comment
Похоже, ваша архитектура определена, но это рискованный путь, если вы заботитесь о производительности и масштабируемости ... Поддержка собственных асинхронных вызовов действительно важна, как пакетирование команд и множественные наборы результатов, которые еще не поддерживаются LINQ to SQL.   -  person RickNZ    schedule 25.11.2009
comment
Что ж, я ценю озабоченность \ точки по поводу выполнения пакетных инструкций и множественных результатов. Я понятия не имею о вызовах native-async. Я предложил базовую архитектуру, но я не вижу, что это «рискованно», потому что я могу обрабатывать сценарий с несколькими наборами результатов, используя VIEW, и вероятность пакетного обновления практически отсутствует.   -  person Hemant Tank    schedule 25.11.2009

Ответы (1)


arrow_upward
0
arrow_downward

Надеюсь, это послужит консолидированным R&D для людей, которые хотят выбрать между ними. Для меня это было давно, и теперь я использую MVC3 и SQL Server в качестве бэкэнда. Итак, у меня есть уровень L2S (LINQ to SQL), который помогает мне получить идеальное сопоставление «ИЛИ» и позволяет мне манипулировать вещами на уровне объекта, а не в любых других формах.

Entity Framework хороша, но L2S обеспечивает больший контроль и проще (это как выбор между Win XP и Vista (EF)). Я остался с L2S, и он работает как шарм!

person Hemant Tank    schedule 30.08.2012