если я использую Платформу Объекта вместо необработанного ADO.NET
Я плохо знаком с Платформой Объекта и CSLA. Я создаю новый CSLA / приложение Silverlight, которое заменит 12-летний Win32 система C++. Старая система пользуется пользовательской библиотекой бизнес-объекта DCOM и использует ODBC для получения до SQL Server. Новая система сразу не заменит старую систему - они должны сосуществовать против той же базы данных в течение последующих лет.
Сначала я думал, что EF был способом пойти, так как это является последним и самым большим. После создания маленькой модели EF и только 2 доступных для редактирования корневых объектов CSLA (у меня в конечном счете будут сотни объектов, поскольку мой DB имеет 800 + таблицы), я серьезно подвергаю сомнению использование EF.
В существующей системе у меня есть потребность много раз, чтобы сделать настройку производительности мелких деталей запросов, которые я могу сделать из-за 100%-го управления сгенерированного SQL. Но кажется в EF, что так много происходит негласно, что я теряю что контроль. Статья как http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html не помогает моему впечатлению от EF.
Людям, кажется, нравится EF из-за LINQ к EF, но начиная с моих критериев передается между клиентом и сервером как объект критериев, что кажется, что я мог создать запросы столь же легко без LINQ. Я понимаю в RIA WCF, что существует проекция запроса (или что-то как этот), где я могу сделать сторону клиента LINQ, который действительно перемещается в сервер перед переводом в фактический SQL так в этом случае, я вижу преимущество EF, но не в CSLA.
Если я буду использовать необработанный ADO.NET, то я буду сожалеть о своем решении 5 лет с этого времени?
Кто-либо еще недавно сделал этот выбор и какой путь Вы шли?
3 ответа
В вашем случае я бы все же выбрал EF, а не делал все вручную.
Почему? EF - особенно в .NET 4 - стал значительно более зрелым. Он позволит вам выполнять большинство операций с базой данных гораздо проще и с гораздо меньшим количеством кода, чем если бы вам пришлось вручную кодировать код доступа к данным.
А в случаях, когда вам нужна абсолютная максимальная производительность, вы всегда можете подключить хранимые процедуры для вставки, обновления, удаления, которые EF4 будет использовать вместо стандартного поведения создания SQL-запросов на лету.
EF4 имеет гораздо лучшую интеграцию хранимых процедур, и это действительно открывает лучшие возможности обоих миров:
- использовать высокую производительность EF для 80% случаев, когда производительность не имеет первостепенного значения
- тонко настроить и создать хранимые процедуры для оставшихся 20% и подключить их к EF4
Посмотрите некоторые ресурсы:
Похоже, у вас есть сочетание требований и несколько решений.
Обычно я оцениваю каждое требование как важное, приятное, но несущественное. А потом посмотрите, что работает.
Я согласен с тем, что сказал @marc_s , вы можете получить лучшее из обоих миров.
Единственное, что я хотел бы сказать, это то, что если это решение будет существовать в течение следующих 5 лет, рассматривали ли вы модульное тестирование?
Там много из примеров о том, как настроить это с помощью EF. (Я лично избегаю ADO.Net только потому, что разделение проблем для модульных тестов настолько сложно.)
Нет простого решения. Я бы выбрал в вашем проекте функцию, на которую у вас уйдет день или около того. Попробуйте разные методы (raw sql, EF, EF + Stored Procs) и посмотрите, что работает!
Объективно взгляните на CSLA - вызовите DataPortal и проверьте стек вызовов.
Затем поместите эти классы на сервер сборки CI, который хранит данные времени выполнения и предоставляет диаграмму разброса по серии запусков.
Затем посмотрите на создаваемый код. Спросите себя, как вы можете использовать такие вещи, как внедрение зависимостей, в свете классов, которые полагаются на статические создатели с защищенными / частными конструкторами.
Затем посмотрите, сколько обязанностей берут на себя классы CSLA.
Наконец, спросите себя, имеет ли смысл создание объектов с разными конструкторами для каждой среды, и спросите себя, как вы будете их тестировать.