Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Общие вопросы по .NET и C# > NHibernate. Расчётное свойство.


Автор: arial 31.10.2007, 12:39
Привет! Научите, пожалуйста, как правильно.
Имеется класс SomeClass.
В классе SomeClass имеется свойство SomeProperty, которое расчитывается на основании свойства Childrens.
К примеру, в SomeProperty, мне нужно посчитать количество Childrens, обладающих неким свойством.
Хотелось бы избежать прописывания в маппинге <property ... formula="SELECT ..." />.

Вопросы:
1. Нужно ли в маппинге прописывать свойство SomeProperty и как-то указывать, что оно не берётся из таблицы, а является расчётным?
2. Как правильнее получать значение SomeProperty: пробежаться циклом по свойству Childrens или использовать CreateCriteria? Как грамотнее?

Маппинг:
Код
<?xml version="1.0"?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Database" namespace="Database">
    <class name="SomeClass" table="SomeTable">
        <id name="Id" column="SomeTableId" type="Int32">
            <generator class="sequence">
                <param name="sequence">SomeTableSeq</param>
            </generator>        
        </id>
        <bag name="Childrens" inverse="true" lazy="true" cascade="all-delete-orphan">
            <key column="SomeId" />
            <one-to-many class="SomeClass2" />
        </bag>    
    </class>
</hibernate-mapping>

Класс:
Код
public class SomeClass
{
  public SomeClass()
  {
  }
  
  private int id;
  public virtual int Id
  {
      get { return id; }
      set { id = value; }
  }    
  
  private IList childrens = new ArrayList();
  public virtual IList Childrens
  {
    get { return childrens; }
    set { childrens = value; }
  }     
         
  private int someProperty;
  public virtual int SomeProperty
  {
    get { 
        // Здесь нужно сделать выборку
        // из Childrens
    }

  }    
}

Автор: Veitmen 1.11.2007, 08:19
Два вопроса. 
1. Я так понял что подсчитывать придется по разным полям иногда? Я бы посоветовал пользоваться фильтрами или создавать IQuery и оттуда смотреть количество полей. Можешь конечно взять просто все и пробежать циклом и может быть ты тогда посчитаешь сразу элементы по разным полям. Смотри как лучше. Сделаешь проперти и считать по разным полям не сможешь. 

2. Большая БД?

Мой совет сделать функцию универсальную подсчета, которой передаешь имя поля. Внутри создаешь или фильтр или IQuery и возвращаешь количество. А в самом проперти класса уже прописываешь вызов этой функции с нужным параметром. А маппинг и правда не трогай. smile 

Автор: arial 1.11.2007, 08:42
Цитата(Veitmen @  1.11.2007,  09:19 Найти цитируемый пост)
1. Я так понял что подсчитывать придется по разным полям иногда?
У ребёнка есть свойства. Родитель будет высчитывать некоторые данные по этим свойствам. Например одно из свойств родителя будет считать общее количество детей, второе свойство родителя будет считать сумму некоторых свойств детей, если дети отвечают некоторым условиям и т.д. в таком духе.
Цитата(Veitmen @  1.11.2007,  09:19 Найти цитируемый пост)
2. Большая БД?
Таблица мизерная. Десяток таблиц, в самой большой таблице, возможно, со временем, наберётся максимум 100'000 строк.

Добавлено через 2 минуты и 26 секунд
Цитата(Veitmen @  1.11.2007,  09:19 Найти цитируемый пост)
Можешь конечно взять просто все и пробежать циклом и может быть ты тогда посчитаешь сразу элементы по разным полям
Я сейчас одним циклом пробегаю по всем детям, и полученные данные рассовываю в соответствующие поля родителя.

Добавлено через 4 минуты и 56 секунд
Цитата(arial)
Нужно ли в маппинге прописывать расчётное свойство родителя и как-то указывать, что оно не берётся из таблицы, а является расчётным
И вот этот вопрос мне покоя не даёт.

Автор: Veitmen 1.11.2007, 09:27
Кажется нашел ответ на твой вопрос:

Цитата

<property
        formula="arbitrary SQL expression" 
/>
(5) formula (optional): an SQL expression that defines the value for a computed property. Computed properties do not have a column mapping of their own. 

Автор: arial 1.11.2007, 09:29
Цитата(arial @  31.10.2007,  13:39 Найти цитируемый пост)
Хотелось бы избежать прописывания в маппинге <property ... formula="SELECT ..." />.


Автор: Veitmen 1.11.2007, 09:38
Чего то я не пойму в чем проблемма... Если тебе надо на уровне БД подсчитывать тогда правь маппинг. Если программно, тогда не прописывай эти поля в маппинге. Вот и все.

Автор: arial 1.11.2007, 09:54
Цитата(Veitmen @  1.11.2007,  10:38 Найти цитируемый пост)
Чего то я не пойму в чем проблемма... Если тебе надо на уровне БД подсчитывать тогда правь маппинг. Если программно, тогда не прописывай эти поля в маппинге. Вот и все.
1. Мне надо посчитать хоть программно (циклом по детям) хоть на уровне БД (createCriteria или createFilter или что там ещё можно придумать), главное, чтобы быстро. Вот я и спрашиваю, как лучше, быстрее, безграбельнее. Не хочу в маппинге запросом выбирать, потому как запрос там на SQL, а диалект на разных базах может отличаться, что может аукнуться при желании в будующем сменить базу данных.
2. Если свойство класса не берётся из базы, то мы просто в маппинге его не описываем и всё. Я правильно понимаю?

Автор: Veitmen 1.11.2007, 10:05
Цитата(arial @ 1.11.2007,  09:54)
1. Мне надо посчитать хоть программно (циклом по детям) хоть на уровне БД (createCriteria или createFilter или что там ещё можно придумать), главное, чтобы быстро. Вот я и спрашиваю, как лучше, быстрее, безграбельнее. Не хочу в маппинге запросом выбирать, потому как запрос там на SQL, а диалект на разных базах может отличаться, что может аукнуться при желании в будующем сменить базу данных.
2. Если свойство класса не берётся из базы, то мы просто в маппинге его не описываем и всё. Я правильно понимаю?

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

2. Маппинг хиберу нужен для того что бы выборки из БД сопоставить свойства твоего класса. То есть если свойство в БД отсутсвует, то мы его не пишем в маппинге. 

Автор: arial 1.11.2007, 10:21
ОК! Спасибо.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)