Платформа объекта ADO.NET или ADO.NET
Я запускаю новый проект на основе ASP.NET и Windows Server.
Приложение планируется, чтобы быть довольно большим и служить большому количеству клиентов, вытягивающих и обновляющих высокие данные изменения частоты.
Я ранее создал проекты с Linq-To-Sql или с Суматохой. Сеть.
Мой план относительно этого проекта состоит в том, чтобы использовать VS2010 и новую платформу EF4.
Было бы замечательно услышать другие опции программистов о разработке с Платформой Объекта
За и против от предыдущего опыта?
Вы думаете, что EF4 готов к производству?
- Я должен рискнуть или просто придерживаться простого хорошего ADO.NET?
3 ответа
Действительно ли EF4 готов к производству, трудно сказать, поскольку официально он еще не выпущен...., но все предварительные опыты и отчеты о нем, кажется, говорят о том, что он довольно хорош.
Однако: вы должны принять во внимание то, что пытается решить EF; это двухслойный подход, один слой отображает схему физического хранения в вашей базе данных (и поддерживает несколько бэкендов), а второй слой - это ваша концептуальная модель, на основе которой вы программируете. И, конечно, между этими двумя слоями необходимо отображение.
Таким образом, EF4 отлично подходит, если у вас большое количество таблиц, если вы поддерживаете несколько бэкендов, если вам нужно иметь возможность сопоставить физическую схему с другой концептуальной схемой и так далее. Она отлично подходит для сложных приложений уровня предприятия.
НО за это приходится платить - эти дополнительные слои влияют на производительность, сложность, ремонтопригодность. Если вам нужны эти функции, вы будете рады заплатить эту цену, без вопросов. Но нужно ли вам это?
Конечно, вы можете вернуться к прямому ADO.NET - но действительно ли вы хотите снова возиться с DataTables, DataRows и нетипизированными конструкциями Row["RowName"]? РЕАЛЬНО????
Поэтому моя рекомендация будет такой:
- если вам нужен только SQL Server в качестве бэкенда
- если у вас есть достаточно простое и понятное отображение одной таблицы базы данных на один объект сущности в вашей модели
тогда: используйте Linq-to-SQL! Почему бы и нет? Он все еще полностью поддерживается Microsoft в .NET 4 - черт, они даже сделали исправления ошибок и добавили несколько битов и частей - это быстро, это эффективно, это бережливо и разумно - так почему бы и нет???
EF 4 теперь в хорошем смысле больше похож на LINQ to SQL; у него есть клавиши FK прямо в объекте, есть методы добавления прямо в наборы объектов и много других приятных функций. Конструктор значительно улучшен, и его главный плюс в том, что он работает с SQL и Oracle и, возможно, с некоторыми другими (если поставщик поддерживает его) вместо LINQ to SQL только с SQL Server.
EF - это будущее; ADO.NET data services - это надстройка веб-службы, плюс она поддерживает генерацию POCO и T4, и любые новые функции будут поддерживать это (LINQ to SQL предназначен только для обслуживания, и наборы данных больше не будут получать никаких изменений).
HTH.
Мой совет - используйте оба. Сначала я думал, что буду использовать только linq to sql и больше никогда не буду касаться ado.net (что меня порадовало, смеется).
Теперь я использую и то, и другое, потому что некоторые вещи linq to sql (и любой ORM, например EF) не могут делать. Мне пришлось сделать несколько массовых вставок, и я сначала сделал это с помощью linq to sql, а для выполнения 500 записей потребовалось более 6 минут (2 минуты для правил проверки, остальные вставлялись в базу данных).
Я изменил его на массовое копирование sql, и теперь он сократился до 2 минут и 4 секунд (4 секунды для всех вставок)
Но, как сказал marc_s, я действительно не хотел возиться с DataTables, DataRows и нетипизированными Строка ["RowName"].
Допустим, моя таблица состояла из 10 столбцов и называлась Table A. Я использовал linq для sql, создал объект класса Table A (new TableA ()) и заполнил его данными. Затем я передал бы этот объект методу, создавшему datarow.
Таким образом, linq to sql сэкономил мне некоторое время, потому что я, вероятно, создал бы класс, поскольку я не хотел бы передавать 10 параметров в метод, который создает строку данных. Я также чувствую, что это дает немного типичности, поскольку вам нужно передать правильный объект, чтобы использовать этот метод, поэтому меньше шансов передать неправильные данные.
Наконец, вы все еще можете использовать linq to sql для вызова хранимых процедур, и это похоже на одну строку кода.
Я бы использовал оба варианта, когда вы заметили, что linq to sql (или в вашем случае EF) работает медленно, тогда просто напишите SP и вызовите его через EF. Если вам нужно делать прямо сейчас.net оцените, что вам нужно сделать, возможно, вы можете использовать EF для большей части кода (чтобы вы могли хотя бы работать с объектами) и только для этой небольшой части ado.net, как то, что я сделал с массовым копированием sql.