|
|
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Как организовать? Кто, что использует? Где, что почитать можно? (Windows.Forms) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 15:33 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Windows Forms разные бывают. NHibernate в связке со Spring.NET, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 15:36 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
а какое отношение к ADO.NET vNEXT? Кто-нибудь пробовал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 15:55 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
На первый взгляд (судил только по статьям) -- слабее NHibernate в очень многих местах, кроме собственно LINQ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 16:18 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
тут пишется, что наоборот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 16:22 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Как все печально там. Товарищ что-то загоняется :) Во-первых, бизнес-классы зачем-то наследуются от System.Data.Objects.Entity Во-вторых, ниасилил: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 4. Создаем своими руками классы, которые представляют наши бизнес-сущности в базе данных Совершенно нормальная практика. К тому же, попробуте напялить этот ADO.NET на готовую БД с названиями полей типа _prod_zakaz Опять же -- для NH есть куча генераторов. 5. Создаем модель данных, указываем Dialect (что сразу привязывает наш готовый ORM к конкретной базе данных и лишает приложение возможности переносимости) Перемешал мухи с котлетами. Dialect указывается в конфигурационном файле приложения и используется исключительно самим NHibernate'ом. А "модель данных" к нему никак не привязана. Что получаем в результате: 1. 6 шагов в случае использования ADO.NET Entity Framework против 8 для NHibernate 2. Используем готовые компоненты Microsoft.NET Framework v3.5 И что с того? Вообще к технологиям не относится. 3. Работаем с базой данных с использованием Generics Начиная с версии 1.2 NHibernate поддерживает их, милости просим. 5. Мы не зависим от базы данных, мы можем изменить провайдера данных, при этом переписывать всю модель не придется (в случае, если структура бд не изменилась), в отличие от NHibernate, где мы четко привязываемся к конкретной БД через dialect. Ерунда. Про "сложные каскадные запросы" -- автор, похоже, не работал с HQL ибн Hibernate Query Language. Поддержка наследования в NH сделана на порядок качественнее. Сложность в пункте "сделаем сохранение внесенных изменений" -- от незнания предметной области. С теми возможностями, что предоставляет NH наличие трех методов более чем оправдано. В простейшем случае хватает SaveOrUpdate(), да и его вызывать не всегда надо. Короче говоря, неадекватное сравнение с явным восхвалением ADO.NET vNext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 16:45 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
palyКак организовать? Кто, что использует? Где, что почитать можно? (Windows.Forms) DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0). Типизированные датасеты, таблицы и адаптеры. Студия по одному селекту генерит xsd схему и код к ней. Получается объектная модел сущности в базе. Если нужно дополнить логику отдельного бизнесс объекта, пишешь partial часть класса, который студия сгенерила. Либо можно обернуть эти объекты в свои, чтоб вообще абстрагироваться от понятий объектов в базе и оперировать понятиями предметной области. Это и есть DAL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2007, 18:14 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
___2222222___ DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0). Типизированные датасеты, таблицы и адаптеры. Это если ну уж совсем по-простому. А там -- чем дальше в лес, тем гуще грабли. Так что забудьте датасеты как страшный сон, мой вам совет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2007, 10:20 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч ___2222222___ DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0). Типизированные датасеты, таблицы и адаптеры. Это если ну уж совсем по-простому. А там -- чем дальше в лес, тем гуще грабли. Так что забудьте датасеты как страшный сон, мой вам совет. А что по вашему в типизиранных объектах плохого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2007, 12:05 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
___2222222___А что по вашему в типизиранных объектах плохого? Да нет, я-то обеими руками "за". Но я "за" типизированные объекты Domain Model, а не типизированные датасеты, адаптеры и всем этом зоопарке а-ля Table Module по Фаулеру. Потому как в простых проектах использование датасетов еще может быть оправдано, но чем больше проект, тем тяжелей, неповоротливей и в целом неудобней становится с ними работа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2007, 12:39 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
есть еще мнения? Кто-нибудь использовал Enterprise Liblary? На сколько там удобно это реализовано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2007, 09:17 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч Потому как в простых проектах использование датасетов еще может быть оправдано, но чем больше проект, тем тяжелей, неповоротливей и в целом неудобней становится с ними работа. +1 paly Кто-нибудь использовал Enterprise Liblary? ИМХО в плане ADO.NET ничего интересного. Код: plaintext Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2007, 21:27 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Так какой же наиболее простой в разработке и поддержке путь? Неужели только 3 человека сталкивались с такой проблемой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2007, 09:37 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
2Sa. А Вы в своих проектах что для постраения DAL/BIZ используете? Простой путь - разумный компромис... Да, вот ещё один вариантец ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2007, 09:45 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Не понятно, что вкладывается в понятие "простой".Если не знаете, что делать - используйте ORM. На мой взгляд, наиболее оптимальный вариант-CSLA(www.lhotka.net) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2007, 11:28 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVa На мой взгляд, наиболее оптимальный вариант-CSLA(www.lhotka.net) Да уж куда как оптимально. Заведомо тормозной вариант, ибо использует рефлекшн по любому поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2007, 23:09 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Делитесь опытом, комрады! Думаю, что многие сталкиваются с такой проблемой и многим будет интересно, как это делают разработчики с опытом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2007, 09:54 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Многое зависит от типа приложения. Я для себя выработал следующую практику, которая, в случае веба и двухзвенки, выглядил примерно следующим образом (использую NHibernate и Spring.NET). Код разделяется на три слоя -- бизнес-объекты, сервисная логика и слой доступа к данным. Бизнес-объекты -- это, собственно, объектная модель предметной области. Честная иерархия классов, выполненная без единого гвоздя и в лучших традициях ООП. Например, вот: Код: plaintext 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. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. То есть ясно, что, например, владелец блога представлен не свойством типа Int64, в котором содержится идентификатор записи в таблице User, а ссылкой на соответствующий объект. Дальше -- сервисная логика. Как видно из кода, логики в бизнес-объектах содержится минимум. Вся логика выносится в отдельный слой. Например: Код: plaintext 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. Да, у меня менеджеры, работающие с БД -- это тоже сервисные классы. Ну так вот. Есть у нас россыпь сервисных классов. Их мы помещаем в Spring.NET'овский IApplicationContext и либо обеспечиваем к нему единую точку доступа (гуглим по поводу Service Locator), либо (если речь о веб-приложении), в тот же IApplicationContext добавляем еще и все страницы. То есть: Код: plaintext 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. (Тут используется встроенная в Spring.NET поддержка ASP.NET). Таким образом, в момент обращения к странице все ссылки на сервисные классы (в данном случае -- ссылка на IBlogManager) уже выставлены Спрингом и всем этим хозяйством можно пользоваться. Ну а слой доступа к данным -- опять же могучая связка NHibernate + Spring.NET: Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2007, 10:36 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
palyесть еще мнения? Кто-нибудь использовал Enterprise Liblary? На сколько там удобно это реализовано? скорость у этой приблуды сильно хромает .... там ведь всё на рефлексии, понимаешь Шайтан ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2007, 13:38 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Осталось еще добавить кучу файлов конфгурации и посмотреть на тот мрак, который твориться с БД, когда на нее напяливают Hibernate. SCSF и WSCF гораздо более вменяемые вещи( с точки зрения наглядности кода и количества затраченных калорий) и с большими возможноcтями, именно благодаря reflection.У любого инструмента есть свои правила применения и если им не следовать, то и будут соответствующие тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 01:10 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaОсталось еще добавить кучу файлов конфгурации и посмотреть на тот мрак, который твориться с БД, когда на нее напяливают Hibernate. А поподробней? SeVaSCSF и WSCF гораздо более вменяемые вещи( с точки зрения наглядности кода и количества затраченных калорий) и с большими возможноcтями, именно благодаря reflection.У любого инструмента есть свои правила применения и если им не следовать, то и будут соответствующие тормоза. Если SCSF -- это Smart Client Software Factory, то заявление о наглядности кода (которого там просто таки тьма тьмущая, и бОльшая часть -- именно что работа с reflection) предстает в довольно мрачном свете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 10:13 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Да, в SCSF большая куча кода, но именно это в купе с reflection, позволяет затрачивать минимум калорий при разработке, что на мой вгляд, более существенно, чем подсчет милисекунд. Например: [CreateNew] public MyPresenter Presenter { set { _presenter = value; _presenter.View = this; } } // при создании View(презантационного слоя) автоматически создается Presenter(обработчик событий) в свою очередь, в нем на автомате создается сервис private IMyService _myService = null; [InjectionConstructor] public Presenter ( [ServiceDependency] IMyService MyService ) { _myService = MyService; } Кратко,внятно и не нужны никакие файлы конфигурации. Еще пример.Привязка комманды к пункту меню private void ExtendMenu() { ToolStripMenuItem item = new ToolStripMenuItem("My Menu Item"); WorkItem.Parent.UIExtensionSites["Tools"].Add(item); WorkItem.Commands[CommandNames.ShowMyItem].AddInvoker(item, "Click"); } Обработчик события [CommandHandler(CommandNames.ShowMyItem)] public void MenuToolsMyMenuItem_Click(object sender, EventArgs e) { IMyView myView = GetOrCreateWorkItemElement<MyView>("MyView"); WorkItem.Workspaces[Constants.WorkspaceNames.MDIWorkspace].Show(myView); // сервис и presenter уже создаются на автомате } У нас основные 3 вида View используются в 10 модулях практически в 99%.Они создаются только один раз, что резко повышает производительность. Благодаря reflection просто решается проблема с правами доступа.Грузятся только те модули, на которые есть доступ,автоматически деактивируются комманды, события, визуальные элементы и тд. Что касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено. PS Все сахера расписывать долго. PSS Это моя точка зрения и я не навязываю ее с фанатизмом другим.Везде есть свои плюсы и минусы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 14:22 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaЧто касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено. Ну что ж вы так. Reflection там уже сто лет как не используется -- вместо этого используются на лету сгенерированные сборки. Т.н. ad-hoc SQL запросы великолепно кэшируются, а то, что там есть какие-то прокси вас ну никак не должно касаться -- их совсем не видно. Насчет "заточу ручками" -- какие запросы собрались затачивать? INSERT/UPDATE/DELETE ? Или SELECT по PK? Или выборку дочерних записей по FK? Чем же вы лучше напишете, чем NH их сгенерирует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 15:35 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Все это "великолепие" я видел в реальных проектах,где все несколько сложнее,чем дернуть выборку блогов.Отсюда и стойкое предубеждение.Рассмотрим простой пример, есть счет и его деталировка с десятью записями, сколько запросов к БД сгенерит Hibernate, учитывая все prepare и иже с ними?Как реализована у вас постраничная выборка с произвольным количеством параметров фильтрации? Как все великолепно кэшируется посмотри кэш запросов. PS C reflection все тоже на лету и невидимо, так почему это все так тревожит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 16:26 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaРассмотрим простой пример, есть счет и его деталировка с десятью записями, сколько запросов к БД сгенерит Hibernate, учитывая все prepare и иже с ними? От одного (с джойном) до двух (SELECT счета, SELECT всех его деталировок) :) Как маппинги напишете, так оно и будет. SeVa Как реализована у вас постраничная выборка с произвольным количеством параметров фильтрации? Хотелось бы поподробней про произвольное количество параметров фильтрации. Но на данный момент у нас в память выбираются все идентификаторы требуемых записей, а потом уже бьются на страницы -- решение ПМа. Про встроенную возможность NH по пэйджингу пока ничего сказать не могу. SeVa Как все великолепно кэшируется посмотри кэш запросов. Все запросы, которым ставишь cacheable в true сохраняются в кэше второго уровня. Точнее, сохраняются идентификаторы записей, вернувшихся в результате запроса. Сами записи лежат (или не лежат -- опять же, как маппинги напишете) в том же кэше. SeVa PS C reflection все тоже на лету и невидимо, так почему это все так тревожит? ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 16:40 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
То, что одним селектом-это замечательно(Hibernate не стоит на месте).Присовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись? Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться? Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное. Кэшировать данные на стороне клиента не всегда возможно. То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 17:10 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaПрисовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись? Можно. Только база-то не нагнется :) ? SeVa Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться? Тут либо Criteria API либо ручной HQL/SQL, поскольку серебряной пули нет, как известно. SeVa Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное. Бесспорно. Но ведь и в вашем случае -- в случае рукописных запросов -- БД придется выполнять те же самые действия. Я же имел в виду кэширование текста SQL для ad-hoc запросов внутри самого NH. SeVa То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет? Всех специфичных возможностей естественно не поддерживает (те же хинты). Про пейджинг не скажу, ибо не пользовался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 17:25 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
1.База быстрее загнется от кучи мелких запросов. 2.Используются только процедуры с готовыми планами выполнения. Допускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 18:06 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVa2.Используются только процедуры с готовыми планами выполнения. Хибернейт и с ними научили работать. SeVaДопускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка. Перед точкой скажу, что сейчас NH используем в промышленном проекте -- если по количественным характеристикам, то это 130+ классов и 170+ Кб XML'я, их описывающего и больше 350 Кб кода самих бизнес-объектов. БД тоже немаленькая -- в настоящий момент около 120 Гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2007, 18:19 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
buser А Вы в своих проектах что для постраения DAL/BIZ используете? Ничего коммерческого или бесплатного. присматриваюсь к nHibernate, слежу за развитием LINQ. Код: plaintext Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2007, 00:15 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
На досуге решил посмотреть, что нового в Hibernat'e,почитал доки, погуглил и нашел в форуме rsdn такой пост: NHibernate for .NET - хорошая ORM ? Так случилось, что для NHibernate тоже приходится писать много своего кода на реальном большом проекте. V>Если не секрет, V>подпорки кокого типа вы писали ? Всего и не упомнишь. Постараюсь вспомнить кое-что: Свои персистеры. Свои проперти аксесоры (захотелось использовать generic-коллекции, а NHibernate для 1.1; также иногда хотелось сохранять NULL для default value-type value и т.д.). Свой кеш-провайдер (захотелось юзать query notifications, а NHibernate ничего про MS SQL Server 2005 не знает). Код, модифицирующий запросы, генерируемые NHibernate. Иногда приходилось прибегать к "ручному" постпроцессингу сгенерированного запроса в строковом (!) виде, т.к. иначе не получалось. Код, позволяющий загружать BO, используя свой произвольный SQL и/или хранимые процедуры. Код, позволяющий выполнять несколько HQL-запросов на чтение в одном database roundtrip. Свой механизм вызова обработчиков до/после выполнения CRUD-операций — IInterceptor и ILifecycle не подошли потому, что в них или не всё отловишь, или сессию нельзя использовать и т.д. Больше не помню PS: Оно, конечно, с виду кажется немного, но на деле нужно было время, чтобы понять, что это нам действительно нужно, понять, как это можно реализовать, и реализовать Их бы усилия да в мирных целях. На мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2007, 13:02 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaНа мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые. Вы сами-то пользовались хотя бы одной ORM? Тем же NHibernate? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2007, 14:15 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Да, грешен(почти 3 года).Hibernate неплохой продукт, но со своими ограничениями.Меня больше устраивают варианты, где у меня руки ничем не связаны, как в том же CSLA.Есть любители и там, которые с данными работают через Hibernate!!!Полная свобода, вы можете сами выбирать каким образом осуществлять доступ к БД.Hibernate-тоталитаризм.Делаем, как я умею, иначе-расстрел. Общим строем ходить я никогда не любил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2007, 15:19 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaДа, в SCSF большая куча кода, но именно это в купе с reflection, позволяет затрачивать минимум калорий при разработке, что на мой вгляд, более существенно, чем подсчет милисекунд. Например: [CreateNew] public MyPresenter Presenter { set { _presenter = value; _presenter.View = this; } } // при создании View(презантационного слоя) автоматически создается Presenter(обработчик событий) в свою очередь, в нем на автомате создается сервис private IMyService _myService = null; [InjectionConstructor] public Presenter ( [ServiceDependency] IMyService MyService ) { _myService = MyService; } Кратко,внятно и не нужны никакие файлы конфигурации. Еще пример.Привязка комманды к пункту меню private void ExtendMenu() { ToolStripMenuItem item = new ToolStripMenuItem("My Menu Item"); WorkItem.Parent.UIExtensionSites["Tools"].Add(item); WorkItem.Commands[CommandNames.ShowMyItem].AddInvoker(item, "Click"); } Обработчик события [CommandHandler(CommandNames.ShowMyItem)] public void MenuToolsMyMenuItem_Click(object sender, EventArgs e) { IMyView myView = GetOrCreateWorkItemElement<MyView>("MyView"); WorkItem.Workspaces[Constants.WorkspaceNames.MDIWorkspace].Show(myView); // сервис и presenter уже создаются на автомате } У нас основные 3 вида View используются в 10 модулях практически в 99%.Они создаются только один раз, что резко повышает производительность. Благодаря reflection просто решается проблема с правами доступа.Грузятся только те модули, на которые есть доступ,автоматически деактивируются комманды, события, визуальные элементы и тд. Что касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено. PS Все сахера расписывать долго. PSS Это моя точка зрения и я не навязываю ее с фанатизмом другим.Везде есть свои плюсы и минусы. очень интересна технология SCSF где про нее почитать подробнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2008, 11:52 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
1. Introduction to CAB/SCSF 2. Programming Microsoft® Composite UI Application Block and Smart Client Software Factory Это букварь покупать не рекомендую.Отдал $10,но одна вода. 3. Labs,Wiki,KB etc 4. Designing Applications using CAB & the Smart Client Software Factory ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2008, 12:35 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
2 Нахлобуч В CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь. К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate. Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:12 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Роман ДынникВ CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь. А так же для заполнения объектов данными, для n-level undo и для кучи остальной требухи. Роман Дынник К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate. Ну вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :) Роман Дынник Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся. "BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:16 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :) хм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно. Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:) кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:25 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю зы вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно. Пока никак, но в планах есть. Будем перетряхивать. зы Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:) Почему же? Вполне сможет. зы кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать. Ну уж "единичных"... У нас система при упавшей БД работала (не целиком, конечно) около 40 минут только за счет кэша второго уровня. И вообще -- мы об одном и том же кэше разговариваем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:34 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
я уверен да :) интересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались. вообще кеш конечно хорошо, это пожалуй один из немногих весомых плюсов от его монстроидальности. автор У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100. В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:49 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
зыинтересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались. Само собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД. зы не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100. Это к начальству :) Впечатление производим -- мол, вона сколько у нас найдено... зы В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать? Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 16:54 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
и сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 17:07 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
зыи сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :) Вот сейчас посмотрел -- самый жирный w3wp.exe на сервере по Task Manager'у занимает 250 Мб. Б о льшая часть -- кеш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2008, 17:17 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит. При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 16:26 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaНахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит. А нет никакого рефлекшена. SeVa При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз. 120 миллионов -- это в денормализованных поисковых таблицах. При показе данные выгружаются из нормализованных таблиц, причем граф получается довольно развесистый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 16:30 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Я к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично. Накладные расходы на нее в таких случаях ничтожны. Выводы о том, что CSLA плохо потому,что я так сказал, мало убедительны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 17:18 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
НахлобучСамо собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД. а откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис. с какой вероятностью попадаете в кеш? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 17:42 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
НахлобучНу вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :) Как она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе. А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений. В CSLA 3.5 рефлексия будет заменена динамическими сборками. Нахлобуч "BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала. Это спорное филосовское утверждение. Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом. В плане передачи между слоями что POCO, что rich - без разницы - все решается настройкой сериализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 22:12 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
кеш-кеш... сложна реализация не самого кеша (что есть всего лишь IdentityMap+Registry), а управления им - кеширование отдельных классов, время кеширования, память отводимая под кеш и чистка кеша в соответствии с ограничениями, слабые ссылки и т.п. Я не специалист в NHibernate, поэтому мне интересно как он справляется с этим управлением? Что имеется ввиду под кешем второго уровня? Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш. И по-моему, в этом контексте, сложна реализация именно кеша первого уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 22:24 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш. И по-моему, в этом контексте, сложна реализация именно кеша первого уровня. можно сказать что на самом деле все наоборот http://www.devx.com/dbzone/Article/29685 (первая ссылка из гугля) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2008, 23:40 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
ъа откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис. с какой вероятностью попадаете в кеш? Вы о чем это сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:08 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaЯ к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично. Накладные расходы на нее в таких случаях ничтожны. Специальный тест писать было лень, поэтому опробовал на том, что есть в текущем проекте. При отключенном Хибернейтовском Reflection Optimizer'е (по сути -- генератор сборок, отвечающих за наполнение объектов данными и их обратный разбор) запрос на 8000+ объектов занимал на 3 секунды больше, чем при включенном оптимизаторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:11 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Роман ДынникКак она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе. Что такое "кешированние вызовов хп"? Кеширование результатов запросов или чего? Нахлобуч А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений. Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли? Роман Дынник Это спорное филосовское утверждение. Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом. ...который легким движением руки выносится в service layer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:15 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
НахлобучЧто такое "кешированние вызовов хп"? Кеширование результатов запросов или чего? кеширование планов запроса. Нахлобуч Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли? Думаю что сначала ищется в хеш-таблице уже распарсенный. Но в целом, думаю что парсинг достаточно частый из-за множества весьма разношерстных HQL-запросов. Нахлобуч...который легким движением руки выносится в service layer. без разницы для service layer чем пользоваться rich или POCO. Легким движением руки выносится и тот и другой тип. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 10:34 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
250 Мб/120мил = 2,5байта на запись!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:19 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVa250 Мб/120мил = 2,5байта на запись!!! Вы большой оригинал :) Вот именно эти 120 миллионов в памяти и не хранятся? Там куча справочных данных, профили пользователей и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:26 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобучхранятся? Вопросительный знак лишний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 13:29 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Да, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:21 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
мне кажется всем должно быть очевидно, что вся база в кеш не падает, подразумевать это по крайней мере глупо, не так ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:23 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
SeVaДа, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда. Ну посудите сами -- зачем кэшировать результаты запросов (представляющие из себя россыпь идентификаторов), которые заведомо не будут повторяться? А в кэше лежит отнюдь не мелкая лабуда, поверьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 14:28 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
Нахлобуч зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю Нахлобуч зы В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать? Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает. НахлобучВы о чем это сейчас? Так в чем фишка не использовать пейджинг скуль сервера? НахлобучТам куча справочных данных, профили пользователей и т.д. У всех к кеше куча справочных данных и профили пользователей. "и т.д." показывай? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 16:01 |
|
||
|
Data Access Layer
|
|||
|---|---|---|---|
|
#18+
ъТак в чем фишка не использовать пейджинг скуль сервера? В том, что он захлебывается. Пробовали уже. ъ У всех к кеше куча справочных данных и профили пользователей. "и т.д." показывай? Охх... Туристический сервер. Поиск и бронирование туров. Загружаем данные, кладем в свою БД. Денормализуем на отдельный сервер, на нем ищем. При выводе из основного сервера читается информация о городах (несколько тысяч), странах (около 200 штук, по-моему), отелях (30+ тысяч, с фотографиями и прочим барахлом), типах питания, звезностях, категориях номеров (все от десятков до сотен единиц). При бронировании вытягиваются данные о туристах, сервисах бронирования, транспортах и прочем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2008, 16:08 |
|
||
|
|

start [/forum/topic.php?all=1&fid=17&tid=1352448]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
70ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 424ms |

| 0 / 0 |
