|
|
|
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 |
|
||
|
|

start [/forum/topic.php?fid=17&msg=34513075&tid=1352448]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
157ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 512ms |

| 0 / 0 |
