Здравствуйте, chico97, Вы писали:

Как автору этой ветки: вот, что пишет Microsoft в Implementing Sun's Java PetStore using Microsoft .Net

The Sun Java Pet Store makes heavy use of Bean Managed Persistence (BMP) in its middle-tier
Enterprise Java Beans (EJB). Essentially, this provides the objects a mechanism to persist their
state to the database. The .NET Pet Shop takes a different approach in that the middle-tier
components make calls to stored procedures in the database. Using stored procedures at the
database level is well established as a best-practice for distributed applications. It provides a
cleaner separation of code from the middle-tier and also helps clarify the transaction context and
scope.Only basic queries are encapsulated in the stored procedures; business logic remains in
the middle tier .NET classes.

Это я к тому, что сами по себе SP это круто, но логику в них держать не надо. Как будет время, нарою материалов для сомневающихся

Здравствуйте, chico97, Вы писали:

C>НЕВЕРЮ что такое могло MS сказать . DataReader — только там где ненадо кешировать, в других случаях с DataSet быстрее.

вот эта статья...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondevelopinghigh-performanceaspnetapplications.asp

DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.

Здравствуйте, mogadanez, Вы писали:

M>DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.
но замечу делает это адаптер сам, специально создавать обьект ридер не нужно

за ссылку спасибо — прочитаю.

Здравствуйте, chico97, Вы писали:

C>Здравствуйте, mogadanez, Вы писали:

M>>DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.
C>но замечу делает это адаптер сам, специально создавать обьект ридер не нужно

Но это не значит что он не тратит на это время....

Здравствуйте, mogadanez, Вы писали:

M>Здравствуйте, chico97, Вы писали:

C>>Здравствуйте, mogadanez, Вы писали:

M>>>DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.
C>>но замечу делает это адаптер сам, специально создавать обьект ридер не нужно

M>Но это не значит что он не тратит на это время....
да, но дело не в трате времени, а в предназначении.
позиционирование этих обектов очень четкое: кеширить — НЕкеширить

Здравствуйте, chico97, Вы писали:

C>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

Позиционирование этих объектов:

Датаридер — легкий и быстрый способ считать из базы какую-либо инфу, используется как правило при простых структурах базы и приложения. Предпочтительный способ доступа к БД для большинства простых приложений.

Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

Причем здесь кэширование???

Здравствуйте, chico97, Вы писали:

C>Здравствуйте, mogadanez, Вы писали:

M>>Здравствуйте, chico97, Вы писали:

C>>>Здравствуйте, mogadanez, Вы писали:

M>>>>DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.
C>>>но замечу делает это адаптер сам, специально создавать обьект ридер не нужно

M>>Но это не значит что он не тратит на это время....
C>да, но дело не в трате времени, а в предназначении.
C>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

что значит кешировать?
Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...
в Win клиенте понятно.

Здравствуйте, mogadanez, Вы писали:

M>что значит кешировать?
M>Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...

а зачем мне за справочниками постоянно в базу лазить?
M>в Win клиенте понятно.

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, chico97, Вы писали:

C>>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

G>Позиционирование этих объектов:

G>Датаридер — легкий и быстрый способ считать из базы какую-либо инфу, используется как правило при простых структурах базы и приложения. Предпочтительный способ доступа к БД для большинства простых приложений.

G>Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

G>Причем здесь кэширование???

после закрытия соединения как можно в DataReader хранить данные?
для этого отлично подходит DataTable.
именно это я и имел в виду.

Здравствуйте, chico97, Вы писали:

C>Здравствуйте, mogadanez, Вы писали:

M>>что значит кешировать?
M>>Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...

C>а зачем мне за справочниками постоянно в базу лазить?

если информация грузится один раз, то ИМХО для производительности по барабану как и чем обрабатывать.
тогда уж удобнее грузить справочиники в IDictionary например.

=) ну у тебя же не только справочники в системе... а именно на наиболее загруженной части надо рассматривать проблему.

Здравствуйте, chico97, Вы писали:

C>а зачем мне за справочниками постоянно в базу лазить?

Имеется в виду, что нужно либо каждый раз за ними лазить на БД, либо сохранять гденть еще, типа Session. Я думаю, что в большинстве случаев действительно, лучше слазить.

Здравствуйте, chico97, Вы писали:

C>Здравствуйте, Gollum, Вы писали:

G>>Здравствуйте, chico97, Вы писали:

C>>>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

G>>Позиционирование этих объектов:

G>>Датаридер — легкий и быстрый способ считать из базы какую-либо инфу, используется как правило при простых структурах базы и приложения. Предпочтительный способ доступа к БД для большинства простых приложений.

G>>Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

G>>Причем здесь кэширование???

C>после закрытия соединения как можно в DataReader хранить данные?
C>для этого отлично подходит DataTable.
C>именно это я и имел в виду.

также для этого чудесно подойдут Собственные entity объекты и их коллекции, с которыми удобно работать.

Здравствуйте, chico97, Вы писали:

C>после закрытия соединения как можно в DataReader хранить данные?
C>для этого отлично подходит DataTable.

Понял, только это не кэширование
Ну тут уже ты должен решить, нужно тебе хранить данные, или сразу пихнуть в интерфейс, например. Ну или почти сразу, через какую-нть простенькую логику.

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, chico97, Вы писали:

C>>а зачем мне за справочниками постоянно в базу лазить?

G>Имеется в виду, что нужно либо каждый раз за ними лазить на БД, либо сохранять гденть еще, типа Session. Я думаю, что в большинстве случаев действительно, лучше слазить.

справочники действительно часто выносят, даже за границы ASP.NET процесса(у нас например WinService + Remoting), но они там как правило хранятся не в виде дата сета а в виде "Справочника"

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, chico97, Вы писали:

C>>после закрытия соединения как можно в DataReader хранить данные?
C>>для этого отлично подходит DataTable.

G>Понял, только это не кэширование
G>Ну тут уже ты должен решить, нужно тебе хранить данные, или сразу пихнуть в интерфейс, например. Ну или почти сразу, через какую-нть простенькую логику.

поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
а под кешированием я имею в виду: загрузил однажды — пользушь долго.

Здравствуйте, chico97, Вы писали:



C>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

Так какая разница как их грузить если это однажды?

Здравствуйте, chico97, Вы писали:

Долго читал вот эту статью, так и не понял прав я был, или нет... Скорее, видимо, нет, чем да :Р
Буду еще копать эту тему — тем более, что она весьма актуальна.

Здравствуйте, mogadanez, Вы писали:

M>Здравствуйте, chico97, Вы писали:



C>>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

M>Так какая разница как их грузить если это однажды?
может разницы и нет, но затем их надо где-то хранить и зачем изобретать велосипед если есть такие прекрасные веши как DataTable, DataSet.
Может лучше сосредоточится на бизнес логике?

Здравствуйте, chico97, Вы писали:

C>Здравствуйте, mogadanez, Вы писали:

M>>Здравствуйте, chico97, Вы писали:

C>

C>>>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>>>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

M>>Так какая разница как их грузить если это однажды?
C>может разницы и нет, но затем их надо где-то хранить и зачем изобретать велосипед если есть такие прекрасные веши как DataTable, DataSet.
C>Может лучше сосредоточится на бизнес логике?

Это и есть логика... справочники ИМХО, удобнее хранить в такой замечательной вещи как HashTable.

Здравствуйте, mogadanez, Вы писали:

M>Это и есть логика... справочники ИМХО, удобнее хранить в такой замечательной вещи как HashTable.

При наличии ключа в DataTable поиск будет ни чем не хуже.