Заранее извиняюсь если что не так написал, только начал изучение етих вопросов.

1.Объясните пожалуйста когда и что лучше использовать.

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

Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.

2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
У объекта Company есть функция CalcCreditRisk которая производит определённые
расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

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

А>Заранее извиняюсь если что не так написал, только начал изучение етих вопросов.

А>1.Объясните пожалуйста когда и что лучше использовать.

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

А> Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.

А>2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
А> У объекта Company есть функция CalcCreditRisk которая производит определённые
А> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
А> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

Посмотри на этот мапер

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

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

А>>Заранее извиняюсь если что не так написал, только начал изучение етих вопросов.

А>>1.Объясните пожалуйста когда и что лучше использовать.

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

А>> Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.

А>>2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
А>> У объекта Company есть функция CalcCreditRisk которая производит определённые
А>> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
А>> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

C_K>Посмотри на этот мапер

Хороший меппер, но только он не дал мне ответов на мой вопрос.

Судя по етому мепперу комманда RSDN активно использует reflection , а все говорят что ето тормоза, видимо ето не так страшно.

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

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

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

А>>>Заранее извиняюсь если что не так написал, только начал изучение етих вопросов.

А>>>1.Объясните пожалуйста когда и что лучше использовать.

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

А>>> Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.

А>>>2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
А>>> У объекта Company есть функция CalcCreditRisk которая производит определённые
А>>> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
А>>> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

C_K>>Посмотри на этот мапер

А>Хороший меппер, но только он не дал мне ответов на мой вопрос.

А>Судя по етому мепперу комманда RSDN активно использует reflection , а все говорят что ето тормоза, видимо ето не так страшно.
Почитайте форум и посмотрите код, с каждым типов ваших данных ассоциируется mapper, который генерится на лету и в итоге никакого рефлекшина нет.

> 2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
> У объекта Company есть функция CalcCreditRisk которая производит определённые
> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

вот этого-то она как раз и не должна: маппер занимается отображением данных БД в данные модели предметной области и обратно, а не обслуживанием всей работы данного объекта с БД. И придуман он для того, чтобы модель предметной области (а она появляется когда БЛ нетривиальная) ничегошеньки не знала о том, как и где она хранится. Это облегчает ее разработку, поддержку и юнит-тестирование.
По сути, тебе бы надо иметь 2 способа вычисления Credit Risk: в памяти и в БД. Можно написать 2 стратежки (впрос как подсовывать, но это тебе виднее), которые наверняка захочется назвать шлюзом ибо похож.

ЗЫ: Мое скромное ИМХО...

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

>> 2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
>> У объекта Company есть функция CalcCreditRisk которая производит определённые
>> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
>> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

КП>вот этого-то она как раз и не должна: маппер занимается отображением данных БД в данные модели предметной области и обратно, а не обслуживанием всей работы данного объекта с БД. И придуман он для того, чтобы модель предметной области (а она появляется когда БЛ нетривиальная) ничегошеньки не знала о том, как и где она хранится. Это облегчает ее разработку, поддержку и юнит-тестирование.
КП>По сути, тебе бы надо иметь 2 способа вычисления Credit Risk: в памяти и в БД. Можно написать 2 стратежки (впрос как подсовывать, но это тебе виднее), которые наверняка захочется назвать шлюзом ибо похож.

Спасибо.
У меня возник вопрос про класс стратегия который будет работать с БД.
Как он должен взаимодейсцтвовать с БД.

КП>ЗЫ: Мое скромное ИМХО...

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

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

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

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

А>>>>Заранее извиняюсь если что не так написал, только начал изучение етих вопросов.

А>>>>1.Объясните пожалуйста когда и что лучше использовать.

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

А>>>> Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.

А>>>>2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
А>>>> У объекта Company есть функция CalcCreditRisk которая производит определённые
А>>>> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
А>>>> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.

C_K>>>Посмотри на этот мапер

А>>Хороший меппер, но только он не дал мне ответов на мой вопрос.

А>>Судя по етому мепперу комманда RSDN активно использует reflection , а все говорят что ето тормоза, видимо ето не так страшно.
C_K>Почитайте форум и посмотрите код, с каждым типов ваших данных ассоциируется mapper, который генерится на лету и в итоге никакого рефлекшина нет.
Спасибо, обязательно почитаю

> Спасибо.
> У меня возник вопрос про класс стратегия который будет работать с БД.
> Как он должен взаимодейсцтвовать с БД.

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

public interface ICreditRiskCalculation {
  int CalculateCreditRisk(Declarant dec);
}

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

Потом пишешь его реализацию, которая аналогично мапперу лезет в БД, вызывает процедуру и получает результат, слегка его обрабатывает и возвращает.

На етом хотелось бы остановится по-подробней.
Етот расчёт действительно делается полностью в Бд в СП. Расчёт имеет отношение к бизнесс логики, поетому он не должен лезть сам в БД, а через какой-то DAL(Mapper)
объект. Что-то у меня каша какая-та в голове.

> Етот расчёт действительно делается полностью в Бд в СП. Расчёт имеет отношение к бизнесс логики, поетому он не должен лезть сам в БД, а через какой-то DAL(Mapper)
> объект. Что-то у меня каша какая-та в голове.

вот представь свою модель. Какой класс в ответе за вычисление этого риска? Я так думаю, что какая-то Заявка (к примеру). Соответсвенно, все желающие получить эти сведения для известной им заявки будут делать так:
Заявка ord;
int risk = ord.GetCreditRisk();

Похож? Далее. Класс Заявка не хочет ничего знать о том, где и как производятся вычисления, верно? Значит его надо от этого абстрагировать. Ты настаиваешь на том, что этот класс должен дернуть какой-то DAL(Mapper). Я же говорю, что не стоит (чтобы у других не было соблазна его дергать), а написать стратегию (в твоих терминах тот же DAL, только с одним методом и никому кроме тебя недоступный). Вот и все. Не надо давать сервис по вычислению риска никому кроме ответственного за это объекта. А уж он должен позаботиться о том, как его предоставить окружающим.
Возможно, я ошибся в предположении и в ответе за этот сервис будет Заявитель, но опять же, тебе виднее...

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

>> Етот расчёт действительно делается полностью в Бд в СП. Расчёт имеет отношение к бизнесс логики, поетому он не должен лезть сам в БД, а через какой-то DAL(Mapper)
>> объект. Что-то у меня каша какая-та в голове.

КП>вот представь свою модель. Какой класс в ответе за вычисление этого риска? Я так думаю, что какая-то Заявка (к примеру). Соответсвенно, все желающие получить эти сведения для известной им заявки будут делать так:
КП>Заявка ord;
КП>int risk = ord.GetCreditRisk();

КП>Похож?

Да, похож.

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

> Давай определимся с терминами.
> Я понимаю под стратегией класс который, отвечает за логику расчёта риска.
> Он взаимодействует с БД. И если я правильно понимаю, то обращение к БД, должно быть в этом же классе. Может это оправдано поскольку основная логика написана в процедуре, но если сама стратегия отягасчена логикой и многократными обращениями в БД, то мы теряем разделение между двумя слоями, или я неправильно понял.

ну, я не знаю, что там за алгоритм Я рассчитываю на эту стратегию как на некоторую оболочку над процедурой (уж коли ты ее написал в БД) и не имеющую никакой логики кроме вызова этой процедуры и представления результатов.
Если есть куча логики, но она требует только вызова (возможно, и многократного) этой процедуры — так и напиши ее в методе ответственного класса, а стратегию оставь как оболочку над вызовом процедуры, и никакого перемешивания слоев не будет.

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

Ну вообщем разобрались.

А как по-поводу первого вопроса, как лучше и правильней.

> А как по-поводу первого вопроса, как лучше и правильней.
и так хорошо, и эдак. см тут раздел Data Source Architectural Patterns, в основном наверное Table Data Gateway и Data Mapper.

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

>> А как по-поводу первого вопроса, как лучше и правильней.
КП>и так хорошо, и эдак. см тут раздел Data Source Architectural Patterns, в основном наверное Table Data Gateway и Data Mapper.

Большое спасибо

Здравствуйте, Аноним, Вы писали:
[..]
А>Давай определимся с терминами.
А>Я понимаю под стратегией класс который, отвечает за логику расчёта риска.
А>Он взаимодействует с БД. И если я правильно понимаю, то обращение к БД, должно быть в этом же классе. Может это оправдано поскольку основная логика написана в процедуре, но если сама стратегия отягасчена логикой и многократными обращениями в БД, то мы теряем разделение между двумя слоями, или я неправильно понял.

Логическое разделение между слоями — не самоцель, а средство. В определенных случаях бывает выгодно выделить частные решения в рамках системы, которые могут (внутри себя) нарушать это самое четкое разделение.

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

А> Интересно что для первого варианта всегда употребляют слово меппер, для второго DAL объект.
Обычно для второго употребляют CRUD объект. (CRUD — create, read, update, delete).

А>2. Есть объект(Company), который заполняется меппeром(CompanyMapper).
А> У объекта Company есть функция CalcCreditRisk которая производит определённые
А> расчёты и должна взаимодействовать с данными из БД. Ето значит что ета функция внутри должна использовать
А> CompanyMapper.Ето меня и смущает, с одной стороны для заполнения объекта используется первый способ(а), а для расчёта второй(б). Что-то у меня не сходится. Помогите разобраться, со всеми возможными вариантами, как прабильно поступать.
Наибольшая проблема таких систем — рассогласования кэша и состояния базы данных. Допустим, у тебя Company изменил аттрибут. Тут ты лезешь в базу в котором лежат старое состояние объекта Company. В результате получаешь неверный результат.

С уважением, Gleb.

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

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

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

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

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

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

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

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

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

Но ето двухсторонняя связь, сохранение ето тоже своего рода отображения полей объекта на поля таблицы.


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

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

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

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

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

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

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