Могу ли я использовать ORM (EF или nHibernate) в клиентском приложении без ущерба для производительности

Question

Я работаю над клиентским приложением WPF. Я никогда не видел, чтобы кто-нибудь использовал ORM на стороне клиента.

Я помещаю здесь некоторый анализ использования ORM в приложении клиент против сервера.

1. По умолчанию это Lazy. Это означает, что до тех пор, пока запрос не будет выполнен в первый раз, ничего не произойдет, но после того, как этот запрос будет кэширован Теперь это можно понять в серверных приложениях, но клиентская часть часто запускается, поэтому я могу использовать готовую загрузку в клиентском приложении?

2. Если dll взломан, будет ли хакеру легко найти данные, поскольку он сразу видит всю структуру базы данных?

3. Какие-либо другие последствия при использовании ORM на стороне клиента?

Спасибо, Omkar

Answer 1

1) EF и nhibernate могут быть настроены на нетерпение 2) не вмешиваться в dll, но оба имеют дизайн типа трубопровода, поэтому код может быть вставлен в трубопровод - например, это делают профилировщики EF / Nhibernate 3) Клиентская сторона не должна быть такой разной - мы использовали EF, сервер / клиент и не нашли различий

Answer 2

Мы используем его для нашего многофункционального клиентского приложения, и у нас не так много проблем с ним.Вы должны немного изменить свое мышление - но нам действительно понравились классы моделей (вместо того, чтобы использовать созданный вручную sql).

• Я бы очень задумался над вашим мнением относительно быстрой загрузки.Я бы попытался разработать приложение с отложенной загрузкой, и если у вас возникли проблемы с ним, попробуйте перейти к активной загрузке.Создание «просмотра объектов данных» и сопоставление сущностей базы данных с этим может помочь с проблемами отложенной загрузки (Айенде Рахин много писал об этих вещах - вы можете проверить его блог: http://ayende.com/blog - хорошим стартером может быть его статья в MSDNhttp://msdn.microsoft.com/en-us/magazine/ee819139.aspx)
• несанкционированные DLL - у меня на самом деле нет мнения на этот счет
• другие последствия - вам нужно думать об управлении сессиями, так как это не так просто, как с серверными приложениями- это было самым большим изменением для нас. Но, с другой стороны, вы освобождаетесь от проблем «уже есть считыватель данных, связанный с этим соединением».

Управление сеансами в целом может быть слишком сложным.Начнем, так что я думаю, что вы должны начать с хорошей структуры - как показано в статье Айенде. Если вам не нравится этот подход, вы можете попробовать "тонкий" ORM, такой как Dapper: http://code.google.com/p/dapper-dot-net/