Какие за и против там используют linq для sql по сравнению с созданием моего собственного datalayer?
Это сообщение похоже на него, могло бы быть релевантным: http://fsharpnews.blogspot.com/2007/05/ffts-again.html
Также: C# / Сравнение производительности F#
самое большое преимущество для чистой математики - то, что заявил PerpetualCoder, F# больше походит на математическую проблему, таким образом, для математика будет легче записать. Это напомнило мне много MATLAB, когда я посмотрел на него.
3 ответа
Что-то не так с наследуя классы, созданные в файл .dbml?
Нет, ничего плохого. Точно так же вы можете заставить сгенерированные классы наследовать от ваших собственных базовых классов или реализовать другие интерфейсы, отличные от готовых.
Являются ли сгенерированные команды SQL эффективно?
Да, но, как всегда, нужно следить за этим. Если вы пишете свои запросы linq, такие же, как и хорошие запросы SQL, сгенерированный sql будет очень эффективным. L2S довольно хорош в оптимизации при некоторых сценариях, например, он устраняет все, что может быть удалено на клиенте и т. Д. Тем не менее, возможно заставить его генерировать плохой SQL так же, как можно написать неэффективное сырое SQL-запросы вручную. Щелкните здесь, чтобы увидеть пример ...
Когда я использовал SQL Server Profiler I заметил, когда я получал список всех записи с использованием linqDataSource для привязки в gridView я бы увидел два запроса выполняется. Первый был ВЫБРАТЬ СЧЕТЧИК (*), а затем ВЫБРАТЬ TOP (PageSizeOfGrid). Почему?
Не знаю, никогда не использовал LinqDataSource. Я предпочитаю использовать необработанные запросы linq, я не поклонник элементов управления / объектов автоматизированных источников данных. Надеюсь, кто-нибудь еще сможет пролить свет на это.
Не лучше ли мне использовать ObjectDataSource получает все записи из хранимой процедуры и кеширования их?
То же, что и предыдущий ... :)
Entity Framework? Не знаю много об этом, но я думаю, что это тоже может быть тяжелый для моих нужд. Большинство моих базы данных довольно простые 10-20 таблицы, у которых может быть много-много отношения. Стоит ли смотреть в?
Дождитесь следующей версии EF. Он будет выпущен как часть .net 4.0. Текущая версия EF не готова к использованию в прайм-тайм, и по какой-то странной причине Microsoft решила не исправлять базовые проблемы, а вместо этого направила все свое время и силы на работу над 4.0. Будет ли он достойным конкурентом / заменой L2S, еще неизвестно. (Я пробовал только бета-версию 1, и она страдает теми же проблемами, что и EFv1; в первую очередь, проблемы с плохо сгенерированными SQL-запросами ... ( ex 1 ex 2 ex 3 и т.д.)
Не совсем ответ на ваш вопрос. Но: Я бы никогда никогда не написал свою собственную библиотеку доступа к данным с нуля. Это отнимает много времени, и это слишком общая проблема, которую не стоит решать для одного приложения.
Доступно довольно много альтернатив, и вы, скорее всего, найдете подходящее решение практически для любого проекта.
- NHibernate
- Linq to Sql
- Entity Framework
- довольно много других ORM
Вы не можете сказать в целом, какой из них «лучший» выбор, но написание собственной библиотеки, скорее всего, худшее.
Если можно настроить таргетинг только на SQL Server, я бы сразу перешел на использование LINQ to SQL, поскольку это очень помогает создавать четкий и поддерживаемый уровень данных. Если производительность вызывает беспокойство, вы можете выборочно использовать прямой код SQL или хранимые процедуры для извлечения некоторых объектов.
Что касается LINQ to Entities, мне нужно было использовать его только один раз, в проекте, в котором мне пришлось использовать ADO .NET Data Services (необработанные классы, сгенерированные LINQ to SQL, не реализуют IUpdateable и поэтому доступны только для чтения при использовании с этой технологией), и я не обнаружил каких-либо убедительных преимуществ перед LINQ to SQL (I ' Я не говорю, что таких преимуществ нет, только то, что я не нашел их для своего конкретного проекта, в котором просто было несколько таблиц базы данных, как у вас).