|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Доброго времени суток! Как я понял, передать Expression от клиента сервису очень трудно и иногда даже опасно в плане стабильности работы сервиса. Но как быть с фильтрами? Например, когда необходимо отфильтровать возвращаемые сервисом данные по нескольким параметрам. Это легко сделать на стороне клиента, но это негативно скажется на производительности, а при условии что записей очень много - это просто недопустимо. Следовательно, фильтровать данные необходимо в момент их получения из базы (да я Кэп). Я сделал такой вариант: "Сущности" Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102.
Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
При таком подходе эту функцию можно будет использовать с любым набором допустимых фильтров, а на стороне сервиса будет генерироваться необходимый LINQ запрос. Хотелось бы узнать мнение по данному подходу. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 16:30 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
__Pavel__, почему трудно и опасно? все зависит о целей и задачи, я бы пошел еще дальше, фильтровал не в момент получения данных из хранилища, а самим хранилищем ( посредством sql запроса) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 17:52 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Где-то в степи, Где-то в степия бы пошел еще дальше, фильтровал ... самим хранилищем ( посредством sql запроса) Так у меня так и получается... яж использую IQueryable<User>, это запрос с отложенным выполнением и он транслируется в SQL запрос именно в момент, когда я получаю список, вызывая метод q.ToList(), объединяя все фильтры, что я применил в один запрос, разве нет? Я проверял значение переменной в момент выполнения, вот результат: при вызове функции со всеми параметрами Код: c# 1. 2. 3.
переменная q (см. в первом посте) транслируется вот в такой SQL запрос SQL Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.
Я не сильно разбираюсь в SQL но все равно понимаю, что там много лишнего нагорожено, самое главное с моей точки зрения - это то, что вот этот кусок кода из функции Users_GetList(***): Код: c# 1. 2. 3. 4.
в итоге превратился в один WHERE, а не в несколько вложенных запросов чего я боялся... Где-то в степия бы пошел еще дальше, фильтровал не в момент получения данных из хранилища Естественно я бы не стал тащить всю коллекцию и локально ее фильтровать, у меня есть совесть)) Поправьте меня если я ошибаюсь, я только начал писать большой проект, не хочу понять свою ошибку в конце... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 20:43 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
__Pavel__Как я понял, передать Expression от клиента сервису очень трудно и иногда даже опасно в плане стабильности работы сервиса. https://github.com/kendo-labs/dlinq-helpers рекомендую изучить проект. всё делается легко и просто. какие хочешь фильтры, и не нужны эти заморочки с SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 21:08 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Где-то в степипосредством sql запроса лично я как-то обходился :) но иногда приходилось скрипя зубами обращаться к SQL, это поддержка легаси проекта на мудацком убожестве под названием "NHibernate", который не жуёт то, что EF щёлкает как орешки даже не моргая без всяких SQL-костылей в HBM-ках. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 21:14 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
hVosttмудацком убожестве под названием "NHibernate" не, он прекрасен. и его возможности еще только допиливаются MS в EF ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2015, 22:52 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
hVostt, когда я имел в виду sql я имел ввиду запрос на сервер данных, как он получен? или обходом дерева или канкатенакцией, без разницы это было сказано в противовес автору - авторСледовательно, фильтровать данные необходимо в момент их получения из базы судя по тому что автор написал он работает с c Linq to Object, код я его не смотрел, для меня это противоистественно, так как вернулся на джаву. зы Афтор - выражай мысли правильно а не вульгарно.. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 07:39 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
__Pavel__ Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Вместо кучи параметров тут удобно применить Parameter Object Pattern . Тогда, кроме всего прочего, параметры пэйджинга p_Count и p_Page можно будет вынести в базовый класс. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 09:40 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
kmawhVosttмудацком убожестве под названием "NHibernate" не, он прекрасен. и его возможности еще только допиливаются MS в EF это когда было? ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 09:50 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Алексей К__Pavel__ Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Вместо кучи параметров тут удобно применить Parameter Object Pattern . Тогда, кроме всего прочего, параметры пэйджинга p_Count и p_Page можно будет вынести в базовый класс. Query Object, (fluent) Query Builder, Specifications... вот это тру. Куча параметров и объект с параметрами -- устаревшие подходы, сложные в сопровождении и тестировании. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 09:53 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Где-то в степикод я его не смотрел, для меня это противоистественно, так как вернулся на джаву. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 09:54 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
hVosttАлексей Кпропущено... Вместо кучи параметров тут удобно применить Parameter Object Pattern . Тогда, кроме всего прочего, параметры пэйджинга p_Count и p_Page можно будет вынести в базовый класс. Query Object, (fluent) Query Builder, Specifications... вот это тру. Куча параметров и объект с параметрами -- устаревшие подходы, сложные в сопровождении и тестировании.Не надо усложнять там, где не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 10:21 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Алексей КНе надо усложнять там, где не надо. это давно стандарт разработки корпоративных приложений ) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 10:36 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
hVosttАлексей КНе надо усложнять там, где не надо. это давно стандарт разработки корпоративных приложений )ГОСТ? ANSI? Давай номер стандарта. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 10:45 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Алексей КhVosttпропущено... Query Object, (fluent) Query Builder, Specifications... вот это тру. Куча параметров и объект с параметрами -- устаревшие подходы, сложные в сопровождении и тестировании.Не надо усложнять там, где не надо.Впрочем, отдай наружу IQueryable, если хочешь универсальности, и не придётся тащить в современный проект устаревшие подходы вроде: "Query Object, (fluent) Query Builder, Specifications... вот это тру". ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 11:01 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Алексей К, отдай наружу IQueryable - опасно.. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 12:03 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Где-то в степиАлексей К, отдай наружу IQueryable - опасно.. Specifications - это безопасно, ага... те же яйца, вид сбоку. Ну хочет если он, я-то тут причём? Я за отдачу наружу Parameter Object-а, способного сериализоваться для передачи через WCF, WebAPI и т. п. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 12:17 |
|
WCF + EF, функция с параметрами вместо IQueryable, хороший ли подход?
|
|||
---|---|---|---|
#18+
Где-то в степиАлексей К, отдай наружу IQueryable - опасно.. с какой кстати опасно? никогда не понимал, не понимаю и не буду понимать это глупой боязни... чё вы так трясётесь за этот IQueryable, это интерфейс, и ничего в нём опасного нет. это уже полностью готовый к употреблению универсальный, всем понимаемый, употребимый в пищу без прожёвывания Query Builder, на который можно повесить спецификации или сделать проекцию, и вообще что угодно. никаких проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2015, 15:03 |
|
|
start [/forum/topic.php?fid=17&msg=39021224&tid=1349519]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
191ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 304ms |
0 / 0 |