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

IT>Здравствуйте, <Аноним>, Вы писали:

IT>>>Проблема второго варианта в том, что он выгладит некошерно, не очень объекто ориентированно

А>>А как сделать кошерно?

IT>Тут либо кошерно либо правильно

Тогда по отдельности, как сделать кошерно и как сделать правильно?

Здравствуйте, <Аноним>, Вы писали:

А>Тогда по отдельности, как сделать кошерно и как сделать правильно?

Моё ИМХО — правильно по возможности не порождать внешних по отношению к объекту связи. Например, имеется объект Company. Он инкапсулирует только то, что касается самого объекта: вычисления для которых достаточно данных самого объекта, навигацию по дочерним объектам, базовую валидацию и т.п. Если для выполнения какой-либо операции, типа CalcCreditRisk, требуется вовлечение внешних по отношению к объекту данных или использование других объектов, то такая операция должна выполняться другим объектам. Неважно как он называется, manager, service, controller, whatever. Т.е. в данном конкретном случае мы должны получить что-то типа:

public class Company
{
    ...
}

public class CompanyManager
{
    public Company GetCompanyByID(int id)
    {
    }

    public void AddCompany(Company company)
    {
    }

    public void UpdateCompany(Company company)
    {
    }

    public void DeleteCompany(Company company)
    {
    }

    public CreditRiskResult CalcCreditRisk(Company company, ...)
    {
    }
}

Весь маппинг выполняется в соответствующих методах менеджера, в идеале в специальном слое — DAL.

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

IT>Здравствуйте, <Аноним>, Вы писали:

А>>Тогда по отдельности, как сделать кошерно и как сделать правильно?

IT>Моё ИМХО — правильно по возможности не порождать внешних по отношению к объекту связи. Например, имеется объект Company. Он инкапсулирует только то, что касается самого объекта: вычисления для которых достаточно данных самого объекта, навигацию по дочерним объектам, базовую валидацию и т.п. Если для выполнения какой-либо операции, типа CalcCreditRisk, требуется вовлечение внешних по отношению к объекту данных или использование других объектов, то такая операция должна выполняться другим объектам. Неважно как он называется, manager, service, controller, whatever. Т.е. в данном конкретном случае мы должны получить что-то типа:

IT>

IT>public class Company
IT>{
IT>    ...
IT>}

IT>public class CompanyManager
IT>{
IT>    public Company GetCompanyByID(int id)
IT>    {
IT>    }

IT>    public void AddCompany(Company company)
IT>    {
IT>    }

IT>    public void UpdateCompany(Company company)
IT>    {
IT>    }

IT>    public void DeleteCompany(Company company)
IT>    {
IT>    }

IT>    public CreditRiskResult CalcCreditRisk(Company company, ...)
IT>    {
IT>    }
IT>}
IT>

IT>Весь маппинг выполняется в соответствующих методах менеджера, в идеале в специальном слое — DAL.


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

Здравствуйте, <Аноним>, Вы писали:

А>Понятно, только по-поводу функции CalcCreditRisk хотелось бы прояснить, такой подход правильный если весь процесс расчёта происодит в БД, а как ето будет выглядеть если расчёт производит обработку информации полученной с БД, т.е ета функция имеет свою логику, ето значит она должна находится не в ДАЛ слое, ибо ДАЛ слой может содержать только логику доступа к БД.

Бизнес логике в БД вообще нечего делать. По многим причинам.
DAL — это слой изолирующий базу данных от нашего приложения. Его задача — переводить термины базы данных в термины приложения. Т.е. из полей таблиц сконструировать объекты и наоборот. Опять же, никакой бизнес логики кроме конструирования объектов в нём быть не должно.

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

IT>Бизнес логике в БД вообще нечего делать. По многим причинам.
IT>DAL — это слой изолирующий базу данных от нашего приложения. Его задача — переводить термины базы данных в термины приложения. Т.е. из полей таблиц сконструировать объекты и наоборот. Опять же, никакой бизнес логики кроме конструирования объектов в нём быть не должно.

А допустимо ли иметь у Company коллекцию Employess?

Здравствуйте, <Аноним>, Вы писали:

А>А допустимо ли иметь у Company коллекцию Employess?

Коллекцию иметь можно, но её заполнение — вопрос спорный.

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

А>> Мне известно два варианта заполнения объекта из базы данных.
А>> а. Использование меппера, который заполняет и редактирует объект.
А>> б. Объект сам себя заполняет и редактирует при помощи DAL объекта который взаимодействует с БД.

IT>Принципиальный вопрос, но с мапперами он связан весьма опосредованно. Mapping — это процесс отображения чего-либо на что-либо. В данном контексте — построение соответствий между полями таблиц базы данных и полями объекта. Твой же вопрос в большей степени относится к Object.Save() vs Save(Object).

IT>В первом случае мы добавляем к связям, которые уже имеет объект ещё одну — связь с источником данных, в котором этот объект хранится, связь с внешним по отношению к объекту миром. Результат — если мы захотим использовать объект повторно, то мы получим в нагрузку и эту связь. Так например, если мы имеем толстого клиента и сервер приложений и хотим использовать объект и там и там, то нам придётся тащить на клиента практически весь бизнес код сервера. В общем, добавление к объекту внешних по отношению к нему связей всегда приводит к куче ограничений и проблем в дальнейшем.

IT>Проблема второго варианта в том, что он выгладит некошерно, не очень объекто ориентированно

А как ты смотришь на сочетание этих подходов?

interface IObjectMapper
{
  void Save(Object o);
}

class Object
{
  public void Save()
  {
    IObjectMapper mapper = MapperFactory.GetMapper("Object");
    mapper.Save(this);
  }
}

Вроде и выглядит кошерно и особых связей не плодится...

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

GIV>А как ты смотришь на сочетание этих подходов?

Отрицательно.

GIV>Вроде и выглядит кошерно и особых связей не плодится...

Даже две связи. Первая с IObjectMapper. Вторая со статическим методом MapperFactory.GetMapper. Причём, если первую связь ещё можно как-то пережить, то вторая порождает бинарную зависимость класса Object от MapperFactory, т.е. Object нельзя использовать без MapperFactory.

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

IT>Даже две связи. Первая с IObjectMapper. Вторая со статическим методом MapperFactory.GetMapper. Причём, если первую связь ещё можно как-то пережить, то вторая порождает бинарную зависимость класса Object от MapperFactory, т.е. Object нельзя использовать без MapperFactory.

Что бы разорвать эту связь нужно при создании или во время инициализации Object каким-то образом передать ему ссылку на IObjectMapper. Что-нибудь типа:

interface IObjectMapper
{
  void Save(Object o);
}

class Object
{
  public Object(IObjectMapper mapper)
  {
    _mapper = mapper;
  }

  IObjectMapper _mapper;

  public void Save()
  {
    _mapper.Save(this);
  }
}

В принципе, вариант более менее рабочий. Связь только с абстрактным интерфейсом, который может быть реализован по разному в разных случаях. Но проблема в том, что этот вариант довольно громоздкий. Предположим IObjectMapper имеет не один, а десять методов связанных с Object. При использовании Object в другом окружении нам нужно будет реализовать, пусть даже как throw new NotImplementedException, все десять методов. В случае использования внешнего по отношению к Object объекта ObjectManager, нам нужно будет реализовать в новом окружении только то, что необходимо в этом окружении. И как правило это совершенно другой набор методов.

Действительно вариант очень громоздкий.
Хотел бы вернуться к начальному вопросу, который я спросил вначале, о реализации CalcCreditRisk — расчтёта риска, определённой фирмы.
Не знаю как лучше всё связать, вот упрощённая логика етого расчёта, хотелось бы услышать совета опытных людей.

Логика расчёта такова :
1. Получают всю негативную информацию о компании собранную за 5 лет (отдельная таблица).
2. Потом бегают по выбранной информации и делают определённый расчёт, в сависимости когда полученна ета информация. Расчёт производят на основе специальной матрицы, которая находится в базе данных.
3. В зависимости от расчёта проверяют надо ли проверять счета проверяемой компании, если да, то выбирают все счета которые когда либо были ограниченны в чём-то. Так-же производят определённый расчёт.
4. В зависимости от расчёта проверяют все дочерние фирмы, а так-же зависимые фирмы и производят для них такой-же расчёт, как и для основной компании, после етого выводится значение "риска".

Вот такая упрощённая логика. Для расчёта требуется дополнительная информация, но в зависимости от промежуточных результатов. Каким образом построить меппары, бизнес объекты, что-бы зависимость между ними была минимальна.
При етом хотелось бы, что бы и тестировать было легко.

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

_>Вот такая упрощённая логика. Для расчёта требуется дополнительная информация, но в зависимости от промежуточных результатов. Каким образом построить меппары, бизнес объекты, что-бы зависимость между ними была минимальна.

Всё очень просто.

Бизнес сущности. Классы описывающие предметную область: Company, CompanyNegativeInfo и т.п. Желательно, что бы эти классы совпадали со структурой таблиц БД. В этом случае маппинг можно сдлать абсолютно примитивным, что существенно упростит DAL. В зависимости от общей архитектуры бизнес сущности могут быть вынесены в отдельный проект.

Бизнес логика. Сервисы или менеджеры (как больше нравится). Всё взаимодействие с БД только через DAL. Никаких исключений. На этот уровень можно вынести только контроль транзакций. Классы BL строго stateless, никакого сохранения состояния между вызовами.

DAL — Data Access. Никакой логики, кроме конструирования объектов из рекордсетов и наоборот. Весь маппинг делается здесь.

Методы BL и DAL вообще можно сделать статическими, но в этом случае мы теряем некоторые возможности по повторному использованию т.к. лишаемся виртуальных вызовов. Классы BL могут использовать DAL либо как агрегированные объекты, либо, опять же, как статические методы, либо создавать их всякий раз при необходимости. Ещё один (не очень кошерный) способ — использование наследования, т.е. когда класс бизнес логики наследуется от соответствующего ему DAL класса. Такая схема неплохо работает, когда имеется много pass-through методов.

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


IT>Бизнес сущности. Классы описывающие предметную область: Company, CompanyNegativeInfo и т.п. Желательно, что бы эти классы совпадали со структурой таблиц БД. В этом случае маппинг можно сдлать абсолютно примитивным, что существенно упростит DAL. В зависимости от общей архитектуры бизнес сущности могут быть вынесены в отдельный проект.

Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.
Никаким образом не должны пересекаться с DAL, не должны знать о своём происхождении.
Бизнес сущности должны быть самодостаточными, т.е недопустимо чтобы за какой-то порцией данных было обращение к DAL, интересно а как-же с lozy load?
В моём случае получается, что функцию расчёта надо вынести из БО Company и перенести её в CompanyManager, который имеет отношение бизнес логике.

Правильно ли расматривать БО, как плоский объект, который должен иметь самую примитивную логику.
Каждый БО должен иметь объект БЛ который оперирует им (CompanyManager <---> Company)


Если у меня запрос состоит из нескольких таблиц, то как надо загружать БО? На каждую таблицу по БО или БО общий на запрос?

IT>Бизнес логика. Сервисы или менеджеры (как больше нравится). Всё взаимодействие с БД только через DAL. Никаких исключений. На этот уровень можно вынести только контроль транзакций. Классы BL строго stateless, никакого сохранения состояния между вызовами.


У меня есть объект DataManager, который абстрагирует работу с базой, правильно ли его создавать в етом слое и передабать объекту ДАЛ, или объект ДАЛ должен сам его создавать.


IT>DAL — Data Access. Никакой логики, кроме конструирования объектов из рекордсетов и наоборот. Весь маппинг делается здесь.

IT>Методы BL и DAL вообще можно сделать статическими, но в этом случае мы теряем некоторые возможности по повторному использованию т.к. лишаемся виртуальных вызовов. Классы BL могут использовать DAL либо как агрегированные объекты, либо, опять же, как статические методы, либо создавать их всякий раз при необходимости. Ещё один (не очень кошерный) способ — использование наследования, т.е. когда класс бизнес логики наследуется от соответствующего ему DAL класса. Такая схема неплохо работает, когда имеется много pass-through методов.

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

_>Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.

Да. Упрощается мапинг.

_>Никаким образом не должны пересекаться с DAL, не должны знать о своём происхождении.

Пересекаться они будут, но с другой стороны. DAL о них будет знать всё.

_>Бизнес сущности должны быть самодостаточными, т.е недопустимо чтобы за какой-то порцией данных было обращение к DAL, интересно а как-же с lozy load?

Это не так. Самодостаточность необязательное условие. Этак можно всю базу через одну сущность вытянуть. К тому же, если я вывожу списко из 1000 ордеров, то одновременное поднятие деталей без необходимости только нагрузит сервера и трафик. Сущности надо поднимать по мере необходимости. У меня обычно получается набор методов типа GetOrderByID, GetOrderDetailsByID, GetOrderListByCustomer и т.п. Первого метода может и не быть, но если есть, то он возвращает только одну записть из таблицы Order, второй метод поднимает Order и все его детали, Items, Addresses и т.п., третий деталей тоже не возвращает, только главные записи. Если мне нужны детали для конкретного ордера, то я вызову потом GetOrderDetailsByID. Но всё это, конечно же, зависит от задачи. Lazy loading я не использую. Красивая идея, но таит в себе множество подвохов. К тому же LL применяется в основном в системах построенных в стиле объектной модели (точнее в стиле пьяной обезъяны, по другому не назовёшь), я же здесь пропогандирую совершенно другой стиль

_>В моём случае получается, что функцию расчёта надо вынести из БО Company и перенести её в CompanyManager, который имеет отношение бизнес логике.

Точно.

_>Правильно ли расматривать БО, как плоский объект, который должен иметь самую примитивную логику.

Самую примитивную да. Что такое 'плоский' я плохо себе представляю.

_>Каждый БО должен иметь объект БЛ который оперирует им (CompanyManager <---> Company)

Интересный вопрос. Иногда это понимается именно так: один Manager — один БО. Тогда лучше думать о таких объектах как о сервисах: один Service — одна подсистема. Как правило такая подсистема обслуживает одну или несколько высокоуровневых сущностей и кучу вспомогательных. Например, OrderingService, всё о заказах.

_>Если у меня запрос состоит из нескольких таблиц, то как надо загружать БО? На каждую таблицу по БО или БО общий на запрос?

Что имеется ввиду, несколько таблиц в одном запросе (JOIN) или несколько запросов за один раз?

В случае с заказами (GetOrderDetailsByID) можно было бы написать такой спрок:

CREATE PROCEDURE GetOrderDetailsByID
    @OrderID int
AS

    SELECT
        Все_поля
    FROM
        Order
    WHERE
        OrderID = @OrderID
    
    SELECT
        Все_поля
    FROM
        OrderItem
    WHERE
        OrderID = @OrderID

GO

Далее DAL при использовании RFD получается примерно такой:

public Order GetOrderDetailsByID(int id)
{
    using (DbManager   db = new DbManager())
    using (IDataReader dr = db
        .SetSpCommand("GetOrderDetailsByID", id)
        .ExecuteReader())
    {
        if (rd.Next())
        {
            Order order = (Order)Map.ToObject(rd, typeof(Order));
            
            rd.NextResult();
            Map.ToList(order.Items, typeof(OrderItem));
            
            return order;
        }
    }
}

BL метод вырождается в pass-through.

IT>>Бизнес логика. Сервисы или менеджеры (как больше нравится). Всё взаимодействие с БД только через DAL. Никаких исключений. На этот уровень можно вынести только контроль транзакций. Классы BL строго stateless, никакого сохранения состояния между вызовами.

_>У меня есть объект DataManager, который абстрагирует работу с базой, правильно ли его создавать в етом слое и передабать объекту ДАЛ, или объект ДАЛ должен сам его создавать.

В случае с транзакциями его необходимо создавать в BL и передавать как параметер в DAL.

IT wrote:
> _>Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.
> Да. Упрощается мапинг.
При этом либо кривеет модель предметной области (что понижает
понимабельность кода, расширяемость и простоту поддержки) либо модель
данных (что понижает производительность). Ищите, друзья, золотую
середину: крайности как правило приводят к геморрою

По всему остальному. Человеку нужно проанализировать общение с компанией
за несколько лет, потом поднять ее счета и т.д. Я продозреваю, что это:
1) большой объем данных
2) он носит исторический (не рабочий) характер (то есть этих данных в
памяти для текущей работы нет), скорее всего на них нет и модели классов

Из этого делаем совершенно тривиальный вывод, что имеет смысл вынести
этот расчет в БД, как говорится "move processing to data, not data to
processing". Вот вопрошающий и принял это решение.
Теперь давайте забудем о мепперах, ибо это понятие всех путает. Меппер
предназначен для того, что ОТОБРАЗИТЬ данные БД в модель предметной
области. Сам объект остается В ПОЛНОМ НЕВЕДЕНИИ о существовании этого
меппера. Об этом знает прикладной код, который загружает объект по
необходимости, сервисный слой (как у IT) и прочая. БО ничего не знает о
DAL, совсем, я думаю и о сервисном слое тоже, разве что о реестре
каком-нибудь, но это отдельная песня. Если LL, то пожалуйста через
посредников, обертки и т.п.: не надо захламлять объект предметной
области, это не его задача, а вопрос реализации оптимизации.
Далее. БО нужна эта функциональность (для каких-нибудь вычислений)? Если
да — то я уже предложил дать ему стратежку, которая будет принадлежать
DAL, ее интерфейс будет определен в модели предметной области и от нее
будет зависеть этот DAL (а он и так зависит, иначе как мапить). Если нет
— вынеси это в отдельный класс DAL, накрой сервисным слоем и пользуйся:
так будет понятнее и спокойнее всем.
Есть конкретные вопросы — милости просим. Тащить эти исторические данные
в память, организовывать для них модель классов не сильно хорошо ИМХО.

IT>Коллекцию иметь можно, но её заполнение — вопрос спорный.
Можно объяснить почему?

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

IT>>Коллекцию иметь можно, но её заполнение — вопрос спорный.
QET>Можно объяснить почему?

Если я закачиваю 1000 ордеров, то заполнение в каждом ордере коллекции айтемов увеличит объём данных в несколько раз, при том, что эта информация может оказаться абстолютно не нужной.

Здравствуйте, Козьма Прутков, Вы писали:

КП>При этом либо кривеет модель предметной области (что понижает понимабельность кода, расширяемость и простоту поддержки) либо модель данных (что понижает производительность). Ищите, друзья, золотую середину: крайности как правило приводят к геморрою

Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.

КП>Из этого делаем совершенно тривиальный вывод, что имеет смысл вынести этот расчет в БД, как говорится "move processing to data, not data to processing".

К сожалению, автор не предоставил нам достаточной информации что бы делать столь однозначные выводы. Выносить логику в БД имеет смысл только если это даёт явные преимущества, как-то повышение произодительности в десятки раз. Но даже и здесь очень часто можно обойтись комбинированными решениями.

КП>Теперь давайте забудем о мепперах, ибо это понятие всех путает. Меппер предназначен для того, что ОТОБРАЗИТЬ данные БД в модель предметной области. Сам объект остается В ПОЛНОМ НЕВЕДЕНИИ о существовании этого меппера. Об этом знает прикладной код, который загружает объект по необходимости, сервисный слой (как у IT) и прочая. БО ничего не знает о DAL, совсем, я думаю и о сервисном слое тоже, разве что о реестре каком-нибудь, но это отдельная песня.

Здесь мы тоже имеем терминологическую путаницу. БО в классическом понимании ООП — это объект несущий в себе как данные, так и логику. Если эти две вещи разделять, то нам нужны новые термины, иначе мы можем начать называть одним термином разные вещи, ты будешь подразумевать под этим бизнес-сущность, а я сервисный объект.

IT wrote:
> Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
ну например не будешь же ты связь БД много-на-много через промежуточную
сущность отображать отдельным объектом? Не будешь.
Допустим, для оптимизации каких-нибудь отчетов ты денормализуешь схему,
что, и модель так же денормализовывать? Нет. Естественно, они будут
похожи, но не всегда один в один: представь, что ты уже имеешь чужую
базу и тебе надо на ней что-то построить. Я не думаю, что твоя модель
предметной области будет идентична наследию, ей богу

> К сожалению, автор не предоставил нам достаточной информации что бы
делать столь однозначные выводы. Выносить логику в БД имеет смысл только
если это даёт явные преимущества, как-то повышение произодительности в
десятки раз. Но даже и здесь очень часто можно обойтись комбинированными
решениями.

Алгоритм довольно сложный, проверяющий всю поднаготную самой компании,
дочерних и родительских компаний. Нужна скорость, поетому перенесли её в
прцедуру.

Это раз. Затем, мои тезисы можно считать своеобразными предположениями,
на которые я опираюсь, и если они не соответствуют действительности —
это сразу станет очевидно и автор меня поправит.

> Здесь мы тоже имеем терминологическую путаницу. БО в классическом понимании ООП — это объект несущий в себе как данные, так и логику. Если эти две вещи разделять, то нам нужны новые термины, иначе мы можем начать называть одним термином разные вещи, ты будешь подразумевать под этим бизнес-сущность, а я сервисный объект.
Да, верно. Я имею в виду бизнес-сущность. При этом, насколько я понимаю
слова вопрошающего, у него приложение построено на domain model и
смущает только то, что бизнес-сущность должна лезть в БД.

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

Здравствуйте, Козьма Прутков, Вы писали:

КП>ну например не будешь же ты связь БД много-на-много через промежуточную сущность отображать отдельным объектом? Не будешь.

Если таблица содержит только ссылки, то не буду. Хотя если указатель на объект воспринимать как объект сам по себе, то вот тебе и мапинг
К тому же такие таблицы очень легко превращаются в обычные объекты. Стоит только нагрузить запись какими-нибудь данными.
Но это плохой пример. Мы говорим о бизнес-сущностях. То что в БД ссылки хранятся тоже в виде полей таблиц — это детали имплементации. Как я уже сказал выше, такие ссылки мапятся в указатели.

КП>Допустим, для оптимизации каких-нибудь отчетов ты денормализуешь схему, что, и модель так же денормализовывать? Нет. Естественно, они будут похожи, но не всегда один в один:

Чаще как раз расширяется модель, а не база. В модели могут присутствавать какие-нибудь агрегированные значения. Если же денормализуется база, то скорее всего это необходимо и модели.

КП>представь, что ты уже имеешь чужую базу и тебе надо на ней что-то построить. Я не думаю, что твоя модель предметной области будет идентична наследию, ей богу

Легаси код — это отдельная песьня. Иногда лучшим решением оказывается введение дополнительного слоя для изоляции это дела.

КП>

КП>Алгоритм довольно сложный, проверяющий всю поднаготную самой компании, дочерних и родительских компаний. Нужна скорость, поетому перенесли её в прцедуру.

КП>Это раз.

Сложность вижу, громадные объёмы данных не вижу.

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

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

IT>>>Коллекцию иметь можно, но её заполнение — вопрос спорный.
QET>>Можно объяснить почему?

IT>Если я закачиваю 1000 ордеров, то заполнение в каждом ордере коллекции айтемов увеличит объём данных в несколько раз, при том, что эта информация может оказаться абстолютно не нужной.

Так а что ж тогда не пойти по пути частичной загрузки этих самых айтемов? Одно большое множество. По мере надобности поступают элементы в него. А уж коллекции — это лишь частное преобразование на множество (Employess, FiredEmployess, ActiveEmployess и т.п.)