Имеем:

1. Web-сервис, возвращающий историю почтовой переписки.
2. Таблицы в базе данных, куда необходимо сохранять корреспондентов и письма.

Задача -- получать сообщения через Web-сервис (только нужные) и сохранять в таблицу в базе сообщения и корреспондентов.

SOAP Web-сервис генерируется Visual Studio автоматически -- здесь без вариантов.
Мапинг таблиц так-же делается автоматически с помощью EF.

Итак, вопрос. Можно ли на этом примере увидеть разницу между Anemic и Rich -подходом к архитектуре?

Если применить Anemic-подход, то придется сделать класс типа ConversationManager с методом Process, в котором получать Id последнего сообщения в базе, делать запрос к серверу с этим Id, получать сообщения, преобразовывать их к классам сущностей, сохранять эти сущности в базу данных.

А если Rich-подход? В чем будет разница?

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

А>Имеем:

А>1. Web-сервис, возвращающий историю почтовой переписки.
А>2. Таблицы в базе данных, куда необходимо сохранять корреспондентов и письма.

А>Задача -- получать сообщения через Web-сервис (только нужные) и сохранять в таблицу в базе сообщения и корреспондентов.

А>SOAP Web-сервис генерируется Visual Studio автоматически -- здесь без вариантов.
А>Мапинг таблиц так-же делается автоматически с помощью EF.

А>Итак, вопрос. Можно ли на этом примере увидеть разницу между Anemic и Rich -подходом к архитектуре?

Нет, потому что у тебя нет логики вокруг источников данных.


А вообще тут типичная ETL задача, для которой код писать не нужно.

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

G>Нет, потому что у тебя нет логики вокруг источников данных.

Как нет логики? Есть:

1. Получить последнюю запись в базе, на основании которой делать запрос.
2. Выделить из сообщения данные корреспондента (там не простая логика).
3. Проверить, существует ли в базе этот корреспондент. Если нет, создать.

Как все это сделать в Rich?

Код для вызова SOAP-метода изменить не можем -- он создан автоматически.

Код для работы с базой (мапинг) так же написан автоматически с помощью EF-кодогенератора.

Где же тогда создать объекты данных и связанные с ними методы, согласно ООП-парадигме?

G>А вообще тут типичная ETL задача, для которой код писать не нужно.

Да? Поясните старому дураку как можно сделать не написав кода (SQL -- тоже код, для нас менее приемлем, нежели C#)? Уточнение SOAP-сервис очень своеобразный, переписать его мы не можем -- не наш + есть непростая логика выделения корреспондента из сообщения.

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

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

G>>Нет, потому что у тебя нет логики вокруг источников данных.

А>Как нет логики? Есть:

А>1. Получить последнюю запись в базе, на основании которой делать запрос.
А>2. Выделить из сообщения данные корреспондента (там не простая логика).
А>3. Проверить, существует ли в базе этот корреспондент. Если нет, создать.

Псевдокод

var msg = ws.GetMessage(...);
var row = ctx.GetSomeObjectByCorellation(msg.Correlation);
if(row == null)
{
    row = new SomeObject();
    cxt.AddSomeObject(row);
}
CopyValues(msg, row);
ctx.SaveChanges();

По сути от полей самих объектов ничего не зависит. Это и называется ситуацией "нет логики".

А>Как все это сделать в Rich?
А>Код для вызова SOAP-метода изменить не можем -- он создан автоматически.
А>Код для работы с базой (мапинг) так же написан автоматически с помощью EF-кодогенератора.
А>Где же тогда создать объекты данных и связанные с ними методы, согласно ООП-парадигме?
Вообще-то partial классы есть. Но и они тут не нужны.

G>>А вообще тут типичная ETL задача, для которой код писать не нужно.

А>Да? Поясните старому дураку как можно сделать не написав кода (SQL -- тоже код, для нас менее приемлем, нежели C#)? Уточнение SOAP-сервис очень своеобразный, переписать его мы не можем -- не наш + есть непростая логика выделения корреспондента из сообщения.
Сложность\кривость сервиса не создает логику. стоит изучать ssis.

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

G>Псевдокод
G>

G>var msg = ws.GetMessage(...);
G>var row = ctx.GetSomeObjectByCorellation(msg.Correlation);
G>if(row == null)
G>{
G>    row = new SomeObject();
G>    cxt.AddSomeObject(row);
G>}
G>CopyValues(msg, row);
G>ctx.SaveChanges();
G>

А как понять что это Rich? ctx -- это DataContext?

G>Сложность\кривость сервиса не создает логику. стоит изучать ssis.

Согласитесь, быстрее сделать используя уже имеющиеся знания, нежели что-то все время изучать. Притом логика может появится (и скорее всего появится) в процессе разработки.

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

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

G>>Псевдокод
G>>

G>>var msg = ws.GetMessage(...);
G>>var row = ctx.GetSomeObjectByCorellation(msg.Correlation);
G>>if(row == null)
G>>{
G>>    row = new SomeObject();
G>>    cxt.AddSomeObject(row);
G>>}
G>>CopyValues(msg, row);
G>>ctx.SaveChanges();
G>>

А>А как понять что это Rich?
А разве оно будет рич? Мне кажется что ты этот код ни в какую сущность не поместишь. Да и смысла в этом нет, это не БЛ, а перекладывание данных их одного хранилища в другое.

А>ctx -- это DataContext?
Да


G>>Сложность\кривость сервиса не создает логику. стоит изучать ssis.

А>Согласитесь, быстрее сделать используя уже имеющиеся знания, нежели что-то все время изучать. Притом логика может появится (и скорее всего появится) в процессе разработки.
Не соглашусь, потому что изучить SSIS можно за два дня и полностью отпадет необходимость поддерживать такой plumbing code.

Вообще позиция "быстрее сделать используя уже имеющиеся знания, нежели что-то все время изучать" напоминает фразу "некогда пилу точить, пилить надо"

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

G>А разве оно будет рич? Мне кажется что ты этот код ни в какую сущность не поместишь. Да и смысла в этом нет, это не БЛ, а перекладывание данных их одного хранилища в другое.

А никак нельзя избавится от этого "ConversationManager" со статическим методом "Process"?

Ведь это явно процедурный подход. Как бы сделать более объектно ориентированно?

G>>>Сложность\кривость сервиса не создает логику. стоит изучать ssis.

А>>Согласитесь, быстрее сделать используя уже имеющиеся знания, нежели что-то все время изучать. Притом логика может появится (и скорее всего появится) в процессе разработки.
G>Не соглашусь, потому что изучить SSIS можно за два дня и полностью отпадет необходимость поддерживать такой plumbing code.

А на чем там писать логику получения корреспондента из сообщения? На SQL? Если на SQL -- то не нужно, врагу не пожелаешь.

Вообще с выходом Linq SQL не используем. Зачем он -- теперь все на C#.

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

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

G>>А разве оно будет рич? Мне кажется что ты этот код ни в какую сущность не поместишь. Да и смысла в этом нет, это не БЛ, а перекладывание данных их одного хранилища в другое.

А>А никак нельзя избавится от этого "ConversationManager" со статическим методом "Process"?
А>Ведь это явно процедурный подход. Как бы сделать более объектно ориентированно?

Ты искренне считаешь что ООП — это когда все методы в экземплярах классов?
Ты глубоко заблуждаешься.

G>Ты искренне считаешь что ООП — это когда все методы в экземплярах классов?
G>Ты глубоко заблуждаешься.

Классы и ООП? Какая вообще связь?