Гуру, поделитесь опытом!
Есть проект и есть некоторое количество редко-изменяемых справочников (напр. должности, типы документов и т.д.), которые периодически нужны для заполнения списков в разных местах приложения. Сами справочники, конечно, хранятся на SQL Server. Думется, их надо раз загрузить (или подгружать по мере надобности) в, скажем, DataSet и пользовать отовсюду.

Вопрос: где хранить этот набор данных? В отдельном классе как статическую переменнуюи и доступ к ней через статические функции? Как это скажется на быстродействии? Или есть другие наработки решения такой штатной ситуации?

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

VK>Гуру, поделитесь опытом!
VK>Есть проект и есть некоторое количество редко-изменяемых справочников (напр. должности, типы документов и т.д.), которые периодически нужны для заполнения списков в разных местах приложения. Сами справочники, конечно, хранятся на SQL Server. Думется, их надо раз загрузить (или подгружать по мере надобности) в, скажем, DataSet и пользовать отовсюду.

VK>Вопрос: где хранить этот набор данных? В отдельном классе как статическую переменнуюи и доступ к ней через статические функции? Как это скажется на быстродействии? Или есть другие наработки решения такой штатной ситуации?

Сам бы я так и сделал. А из-за чего там может быть проблема с производительностью?

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

VK>>Есть проект и есть некоторое количество редко-изменяемых справочников (напр. должности, типы документов и т.д.), которые периодически нужны для заполнения списков в разных местах приложения. Сами справочники, конечно, хранятся на SQL Server. Думется, их надо раз загрузить (или подгружать по мере надобности) в, скажем, DataSet и пользовать отовсюду.

VK>>Вопрос: где хранить этот набор данных? В отдельном классе как статическую переменнуюи и доступ к ней через статические функции? Как это скажется на быстродействии? Или есть другие наработки решения такой штатной ситуации?

_>Сам бы я так и сделал. А из-за чего там может быть проблема с производительностью?

Доступ к статическим переменным происходит медленнее, но при небольшом объеме тоже не думаю, что будет критично.
Сам сделал также, но решил уточнить у сообщества.

Спасибо

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

VK>Доступ к статическим переменным происходит медленнее

... Почему?

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

[... skipped ...]

VK>Доступ к статическим переменным происходит медленнее,

Бред

VK>VK>но при небольшом объеме тоже не думаю, что будет критично.
VK>Сам сделал также, но решил уточнить у сообщества.

VK>Спасибо

Hello, "Oyster"

> VK>Доступ к статическим переменным происходит медленнее,
> Бред
>

А если подумать?

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

TK>Hello, "Oyster"

>> VK>Доступ к статическим переменным происходит медленнее,
>> Бред
>>

TK>А если подумать?

Раз ты ответил, то, видимо, я ошибаюсь. Но всё равно не вижу, почему доступ к статической переменной int x будет происходить медленнее, чем к переменной экземпляра класса int y.

Hello, "_FRED_"
>
> VK>Доступ к статическим переменным происходит медленнее
> ... Почему?

Такое бывает в случаях, когда .net разделяет генерируемый jit-ом код между
несколькими доменами. В такой ситуации общий код не может напрямую работать
со статической переменной (доменов несколько и переменных => несколько).
поэтому, используется дополнительная косвенность при обращении к static
переменной.

конечно, можно код между доменами не разделять. тогда, никаких проблем не
будет...

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

TK>Hello, "Oyster"

>> VK>Доступ к статическим переменным происходит медленнее,
>> Бред
>>

TK>А если подумать?

А... ну если в случае, описанном выше (с доменами), — тогда да, согласен...

Но в общем случае нет

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

>> VK>Доступ к статическим переменным происходит медленнее
>> ... Почему?

TK>Такое бывает в случаях, когда .net разделяет генерируемый jit-ом код между
TK>несколькими доменами. В такой ситуации общий код не может напрямую работать
TK>со статической переменной (доменов несколько и переменных => несколько).

Но внутри одного домена по-прежнему всё будет "хоккей"?

TK>поэтому, используется дополнительная косвенность при обращении к static
TK>переменной.

На сколько это дорого?

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

[... skipped ...]

TK>>поэтому, используется дополнительная косвенность при обращении к static
TK>>переменной.

_FR>На сколько это дорого?

http://blogs.msdn.com/ricom/archive/2005/02.aspx

The runtime supports a lightweight process-like environment called an AppDomain. Each AppDomain has its own copy of all static variables. Because of this, any domain nuetral code must use 5-10 instructions to access static fields of just 1. The JIT can optimize many cases (allowing one fetch of AppDomain variables to serve many static field fetches in the same method), but there are cases when no optimization can be done. Domain Nuetral code is more common in Whidbey. Static field access overhead is actually worse than write barriers in the worst case: the static field access goes from one cycle to roughly ten cycles. However because the overhead of field fetches can be combined (and pulled out of loops) the impact of slower field fetch is generally less than that of write barriers. It has no measurable impact at all in many scenarios (for instance the framework code tends to not use static much).

Можно и так... Быстрее будет, если заюзаешь Cache ...

Во втором фреймверке у меня вообще динамически генерятся енумы, которые содержат все необходимые данные
И немедленно выпил ...

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

VK>>Вопрос: где хранить этот набор данных? В отдельном классе как статическую переменнуюи и доступ к ней через статические функции? Как это скажется на быстродействии? Или есть другие наработки решения такой штатной ситуации?

_>Сам бы я так и сделал. А из-за чего там может быть проблема с производительностью?

"Вернемся к баранам" Остались непонятки...
Создаем класс со статическими переменными. Как теперь организовать использование этих переменных изнутри UserControls? Ведь на этапе проектирования контролов эти переменные еще не существуют. Такое вообще возможно? Через внешние свойства контролов?

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

VK>>>Вопрос: где хранить этот набор данных? В отдельном классе как статическую переменнуюи и доступ к ней через статические функции? Как это скажется на быстродействии? Или есть другие наработки решения такой штатной ситуации?

_>>Сам бы я так и сделал. А из-за чего там может быть проблема с производительностью?

VK>"Вернемся к баранам" Остались непонятки...
VK>Создаем класс со статическими переменными. Как теперь организовать использование этих переменных изнутри UserControls? Ведь на этапе проектирования контролов эти переменные еще не существуют. Такое вообще возможно? Через внешние свойства контролов?

В дизайн-тайме, например из TypeConverter'а, вполне реально получить доступ к статическим свойствам других типов (например, есть же доступ к переменныем перечислений). Вот если значение статического свойства надо передать в аттрибут, то нельзя, но их можно проставить в момент инициализации, например в конструкторе UserControl.

VK>>"Вернемся к баранам" Остались непонятки...
VK>>Создаем класс со статическими переменными. Как теперь организовать использование этих переменных изнутри UserControls? Ведь на этапе проектирования контролов эти переменные еще не существуют. Такое вообще возможно? Через внешние свойства контролов?

_FR>В дизайн-тайме, например из TypeConverter'а, вполне реально получить доступ к статическим свойствам других типов (например, есть же доступ к переменныем перечислений). Вот если значение статического свойства надо передать в аттрибут, то нельзя, но их можно проставить в момент инициализации, например в конструкторе UserControl.

_FRED_
Чуток подробнее можно? А то опыта только набираюсь...
Спасибо

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

VK>>>"Вернемся к баранам" Остались непонятки...
VK>>>Создаем класс со статическими переменными. Как теперь организовать использование этих переменных изнутри UserControls? Ведь на этапе проектирования контролов эти переменные еще не существуют. Такое вообще возможно? Через внешние свойства контролов?

_FR>>В дизайн-тайме, например из TypeConverter'а, вполне реально получить доступ к статическим свойствам других типов (например, есть же доступ к переменныем перечислений). Вот если значение статического свойства надо передать в аттрибут, то нельзя, но их можно проставить в момент инициализации, например в конструкторе UserControl.

VK>_FRED_
VK>Чуток подробнее можно? А то опыта только набираюсь...

Не совсем я пока понимаю, что именно требуется, но попробую так:

using System;

namespace WindowsApplication1
{
  #region Using directives

  using System.Data;
  using System.Data.Common;
  using System.Data.SqlClient;
  using System.Diagnostics;
  using System.Windows.Forms;

  #endregion Using directives

  //Здесь хранятся статические данные
  public class DataStore
  {
    private DataStore() {
    }

    public static DataSet MyDataSet;

    // Заполняем статические данные
    static DataStore() {
      MyDataSet = new DataSet();
      using(SqlDataAdapter adapter = new SqlDataAdapter()) {
        using(SqlConnection connection = new SqlConnection("Server=ServerName; Database=DatabaseName; User ID=sa; Password=;")) {
          using(SqlCommand command = new SqlCommand("SELECT * FROM A; SELECT * FROM B;", connection)) {
            adapter.SelectCommand = command;
            adapter.TableMappings.Add("Table", "A");
            adapter.TableMappings.Add("Table1", "B");
            adapter.Fill(MyDataSet);
          }//using
        }//using
      }//using
    }
  }

  // А здесь будем ихз использовать
  public class MyComponent : UserControl
  {
    public MyComponent() {
      view = new DataGrid();
      view.Dock = DockStyle.Fill;
      Controls.Add(view);
    }

    protected override void OnLoad(EventArgs e) {
      try {
        if(DesignMode) { // "...Используем статические переменные..." "...этапе проектирования..."
          view.DataSource = DataStore.MyDataSet;
          view.DataMember = "A";
        }//if
      } finally {
        base.OnLoad(e);
      }//try
    }

    private DataGrid view;
  }
}

Если положить такой компонент на форму, то в дизайн-тайме он покажет содержимое таблицы "А".

_FRED_

_FR>    protected override void OnLoad(EventArgs e) {
_FR>      try {
_FR>        if(DesignMode) { // "...Используем статические переменные..." "...этапе проектирования..."
_FR>          view.DataSource = DataStore.MyDataSet;
_FR>          view.DataMember = "A";
_FR>        }//if
_FR>      } finally {
_FR>        base.OnLoad(e);
_FR>      }//try
_FR>    }

_FR>Если положить такой компонент на форму, то в дизайн-тайме он покажет содержимое таблицы "А".

То, что нужно!
Как раз и была проблема инициализации статических переменных в дизайн моде.
И про проверку DesignMode думал, но что-то переклинило, блин, мудрить начал.
Очень помогли, спасиб!

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

VK>И про проверку DesignMode думал, но что-то переклинило, блин, мудрить начал.

DesignMode — не очень надёжное средство для определения того, что компонент действительно в этом режиме . Это много раз обсуждалось и здесь и на гдн. Так что поиск в помощь .