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

A>У вас есть мысли как сделать использование проще?

Первое что пришло в голову — просто грузить классы из сборки, не? Для реализации под каждый тип хранилища — своя сборка.

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

Doc>Это отчасти зависит от архитектуры самого приложения. В частности, если правильно созданы QueryObject, то можно сделать их варианты оптимальные под конкретные хранилища и не затрагивать изменениями BL.

К сожалению, только в теории.

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

A>>У вас есть мысли как сделать использование проще?

Doc>Первое что пришло в голову — просто грузить классы из сборки, не? Для реализации под каждый тип хранилища — своя сборка.
Нет, мы о разном говорим.
Реализация фабрики это отдельная задача. Причем не такая уж и сложная. Современные IoC контейнеры отлично справляются с автоматической регистрацией достаточно сборку или нэймспэйс им подсунуть.

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


Почему я сказал, что задача с фабрикой не такай уж и сложная, хотя код в ней будет в разы сложнее чем само Query?
А потому что ошибку в фабрике найдешь ты сам, причем буквально при первом запуске. А вот если ты что-то сделал не так с query, то ошибку в лучшем случае найдет тестер, но что-то мне говорит, что это будет заказчик, да еще и не сразу.


СУВ, Aikin

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

Doc>>>Причем это зависит не от нагрузки, а именно от задач.
A>>Вот про это я хочу послушать.
Doc>Ну а я привел примеры.
"А давайте еще и поддержку XML сделаем" -- это не задача.
"Поддержка клиентов, которые не могут/не хотят ставить сервер баз данных" -- вот это задача. Но эту задачу решают embeded базы данных.

Ну так как? Будут реальные примеры?

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

A>Реализация фабрики это отдельная задача. Причем не такая уж и сложная. Современные IoC контейнеры отлично справляются с автоматической регистрацией достаточно сборку или нэймспэйс им подсунуть.

Собственно это я и предложил.

A>Я говорю о количестве мест в приложении, которые придется изменить если изменится логика подсчета фавортиных заказов. Вот это действительно важно.
A>Чем больше количество мест для изменения, тем больше возможностей и вероятности про что-то забыть и получить трудноуловимый баг.

Подождите, мы о чем — о переделке QO и DAL или замене заранее спроектированных для этого OQ? Во втором случае надо будет просто загрузить сборку с оптимизированными под данное хранилище QO.

A>А потому что ошибку в фабрике найдешь ты сам, причем буквально при первом запуске. А вот если ты что-то сделал не так с query, то ошибку в лучшем случае найдет тестер, но что-то мне говорит, что это будет заказчик, да еще и не сразу.

А если такая же ошибка будет в Linq выражении? Её также найдет только или текстер или заказчик.

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

A>Ну так как? Будут реальные примеры?

Т.е. движки вроде BlogEngine выдуманный пример? Или сайты для малого бизнеса, которым по типу данных без разницы где хранилища. Т.е. мне, как разработчику удобно иметь библиотеку DAL, которую можно использовать для любого из этих сайтов. Все это реальные задачи?

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

A>>Я говорю о количестве мест в приложении, которые придется изменить если изменится логика подсчета фавортиных заказов. Вот это действительно важно.
A>>Чем больше количество мест для изменения, тем больше возможностей и вероятности про что-то забыть и получить трудноуловимый баг.

Doc>Подождите, мы о чем — о переделке QO и DAL или замене заранее спроектированных для этого OQ? Во втором случае надо будет просто загрузить сборку с оптимизированными под данное хранилище QO.
Я говорю о готовности решения к изменениям. Эту характеристуку называют maintainability (за неимением нормального русского эквивалента).
Некоторые люди, только что закончившие ВУЗ, могут решить любую задачу за ночь. Не нужно говорить, что maintainability таких решений обычно стремиться к 0.


Doc>А если такая же ошибка будет в Linq выражении? Её также найдет только или текстер или заказчик.
Такая же не будет. Linq выражение ты можешь охватить взглядом и легко протестить, а вот проследить связи через этерфейсы уже сложнее. Я не говорю, что сложно, но сложнее.
Особенно сложно будет если вы поддерживаете десяток провайдеров. В этом случае, например, можно забыть внести эти изменения в Query для XML. Или сделать ошибку только в query для Postgres.

Doc>Собственно это я и предложил.
Да, именно это вы и предложили. Но это совсем не то на что я хотел обратить внимание.

СУВ, Aikin

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

A>>Ну так как? Будут реальные примеры?

Doc>Т.е. движки вроде BlogEngine выдуманный пример? Или сайты для малого бизнеса, которым по типу данных без разницы где хранилища. Т.е. мне, как разработчику удобно иметь библиотеку DAL, которую можно использовать для любого из этих сайтов. Все это реальные задачи?
Я выделил пример чего я хотел увидеть в предыдущем сообщении.
Я хочу увидеть пример задачи, которая бы требовала поддержки всевозможных (экзотических) хранилищ.

Например задача для движка блога:
"Поддержка клиентов, которые не могут/не хотят ставить сервер баз данных" -- эту задачу решают embeded базы данных.

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

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

A>>Ну так как? Будут реальные примеры?

Doc>Т.е. движки вроде BlogEngine выдуманный пример? Или сайты для малого бизнеса, которым по типу данных без разницы где хранилища. Т.е. мне, как разработчику удобно иметь библиотеку DAL, которую можно использовать для любого из этих сайтов. Все это реальные задачи?

Ты немного путаешь. Для BlogEngine и прочих engine, изначально ставится задача поддержки определенных типов хранилищ. Но нет задачи сделать возможность "заменить dal". Во всех этих *engine DAL затачивается под общее подмножество функций хранилищ, а не делается настолько абстрагированным чтобы подставить любое хранилище.

Кстати если рассматривать современные ORM, то они решают задачу смены одной DBMS на другую самостоятельно, не нужно их абстрагировать.

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

A>Я выделил пример чего я хотел увидеть в предыдущем сообщении.
A>Я хочу увидеть пример задачи, которая бы требовала поддержки всевозможных (экзотических) хранилищ.

Судя по разговору, я понимаю что дальше будет. Например я скажу, что-то вроде "поддержка оптимальной работы ПО у клиентов, вне зависимости от типа хранилища." Вы затем скажете что это решается и так, без всяких "заморочек" с DAL.

Я замечаю что разговор переходит в плоскость, будто я утверждаю что софт с Linq в BL развалится до запуска. Хотя я такого не говорил.

A>Например задача для движка блога:
A>"Поддержка клиентов, которые не могут/не хотят ставить сервер баз данных" -- эту задачу решают embeded базы данных.

Даже если не уходить с SQL, то разные БД имеют свои ограничения и баги. Про mySQL я уже писал, embeded как правило не поддерживают транзакции и т.д. Все равно придется учитывать все это в DAL и OQ.

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

A>Я говорю о готовности решения к изменениям. Эту характеристуку называют maintainability (за неимением нормального русского эквивалента).

Хорошо, как вы можете доказать свое утверждение, что maintainability "Linq в BL" больше, чем "Linq в QO"?
Кроме того, почему если я не трогаю BL и переписываю только сборку с QO, это хуже чем копаться сразу в BL?

Doc>>А если такая же ошибка будет в Linq выражении? Её также найдет только или текстер или заказчик.
A>Такая же не будет.

С чего бы это? В реальном QO содержится тоже Linq выражение. Так или иначе мы выйдем или на что-то вроде
var someResult = mydata.where(n => id==n)...[итд]
или на что-то вроде
var someResult = dal.executeQuery(new GetSomeDataByIdQuery(id));

Ну да, во втором слчае на одно нажатие F12 больше Да и что-то подсказывает, что для тестов лучше завернуть mydata.where(n => id==n)...[итд] в отдельный метод в отдельном классе запросов. Поэтому кол-во нажатий F12 сравняется.

Ну и да, с контейнером будет чуть сложнее. Но это только на случай, когда выбор хранилища идет в рантайме.

Doc>>Linq выражение ты можешь охватить взглядом и легко протестить, а вот проследить связи через этерфейсы уже сложнее. Я не говорю, что сложно, но сложнее.

Сложно охватить взглядом класс QO из ~20 строк, да и то, все кроме метода с Linq выражением приячется сворачиванием.

A>Особенно сложно будет если вы поддерживаете десяток провайдеров. В этом случае, например, можно забыть внести эти изменения в Query для XML. Или сделать ошибку только в query для Postgres.

А UnitTest на что? QO очень лего тестятся как против массива, так и (где специфика СУБД) против тестовой базы.

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

Doc>С чего бы это? В реальном QO содержится тоже Linq выражение. Так или иначе мы выйдем или на что-то вроде
Начинаем все сначала. Смысл в QO которое содержит только Linq выражение? ИХМО, чтобы QO имело смысл, нужно несколько реализаций под разные хранилища. Поэтому и сложнее.

Doc>Ну и да, с контейнером будет чуть сложнее. Но это только на случай, когда выбор хранилища идет в рантайме.
А какие варианты? Выбор конкретной реализации всегда в рантайме происходит. Если провайдеров больше одного, конечно.

A>>Особенно сложно будет если вы поддерживаете десяток провайдеров. В этом случае, например, можно забыть внести эти изменения в Query для XML. Или сделать ошибку только в query для Postgres.
Doc>А UnitTest на что? QO очень лего тестятся как против массива, так и (где специфика СУБД) против тестовой базы.
А, так у вас еще и юнит тесты есть на всю логику. И интэгрэйшен сервер настроен. Так?

Это реально так и есть, или это теоретические рассуждения?
Я говорю за практику. Вы, похоже, о теории.

СУВ, Aikin

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

Doc>Вы затем скажете что это решается и так, без всяких "заморочек" с DAL.
Нет, мы перешли в плоскость бизнесс задач. Я буду говорить с точки зрения стоимости реализации и экономической эффективности. А еще я буду говорить о том, что очень часто решения проблем преподносятся как требования (задачи) (привет, Гапертон, спасибо за науку).

Doc>Например я скажу, что-то вроде "поддержка оптимальной работы ПО у клиентов, вне зависимости от типа хранилища."
Извините, но это не бизнесс задача. Это маркетинговый лозунг от человека далекого от IT.
Как вы собираетесь решать эту задачу? А главное: как вы сможете понять что решили ее?


Doc>Я замечаю что разговор переходит в плоскость, будто я утверждаю что софт с Linq в BL развалится до запуска. Хотя я такого не говорил.
И близко не переходит. Я просто хочу понять откуда могут появиться требования о поддержке хранилища в виде XML вместе с нормальными БД.

Doc>Про mySQL я уже писал, embeded как правило не поддерживают транзакции и т.д. Все равно придется учитывать все это в DAL и OQ.
XML-файлы, очевидно, поддерживают.

СУВ, Aikin

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

Doc>embeded как правило не поддерживают транзакции и т.д.

Какие именно? Access, SQLite и SqlCe поддерживают. Embedded Firebird не пробовал, но наверняка тоже поддерживает.

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

IT>Какие именно? Access, SQLite и SqlCe поддерживают. Embedded Firebird не пробовал, но наверняка тоже поддерживает.

У меня SqlCe падала на попытке использовать транзакции с Exception что не поддерживается.

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

IT>Для PL придумано семейство паттернов MVC.

Я то думал что оно и для BL тоже

IT>Это как? Слои есть, функционал есть, а размазывание его по слоям нет? Тогда зачем тебе слои?

А слои нужны для размазывания функционала? Это что-то новое.

IT>>>Как минимум тебе понядобится два дополнительных метода (по одному в DAL и BL)
Doc>>Для чего? Можно пример (псевдокод)?

IT>UI:

IT>

IT>...

IT>var customers = MyBusinessLogic.GetCustomers();
IT>...
IT>

IT>BL:

IT>

IT>List<Customer> GetCustomers()
IT>{
IT>    return MyDataAccess.GetCustomers();
IT>}
IT>

IT>DAL:

IT>

IT>List<Customer> GetCustomers()
IT>{
IT>    return db.Execute(...);
IT>}
IT>

Ну при таком построении DAL не мудрено что вам мерещется размазывание по слоям.

Doc>>Можно цитату, не вырванную из контекста, где я говорил о что повторное использование это особенность только слоев?
IT>Посмотри выше по ветке.

Не нашел. Укажите.

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

IT>>Для PL придумано семейство паттернов MVC.
Doc>Я то думал что оно и для BL тоже

MVC для BL? Что-то я всё больше и больше убеждаюсь, что у кого-то из нас двоих, но не у меня, либо сплошная каша в голове, либо проблемы с терминологией.

IT>>Это как? Слои есть, функционал есть, а размазывание его по слоям нет? Тогда зачем тебе слои?
Doc>А слои нужны для размазывания функционала? Это что-то новое.

Путаем причину со следствием.

Doc>Ну при таком построении DAL не мудрено что вам мерещется размазывание по слоям.

Всё остальное вариации на тему. Хотя, конечно, иногда бывает, что за деревьями леса не видно.

Впрочем, мы можем посмотреть на твой код и решить. Но ты видимо очень сильно стесняешься его показать.

IT>>Посмотри выше по ветке.
Doc>Не нашел. Укажите.

Нет никакого желания перелапачивать весь топик.

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

IT>MVC для BL?

"и для BL тоже"

IT>Что-то я всё больше и больше убеждаюсь, что у кого-то из нас двоих, но не у меня, либо сплошная каша в голове, либо проблемы с терминологией.

MVC отделяет PL и BL (которая по сути тут M) через C. Ваша версия? Хотя вы уже в BL UI включали (и потом неумело отдувались).

IT>Путаем причину со следствием.

Это вы путать начали.

Doc>>Ну при таком построении DAL не мудрено что вам мерещется размазывание по слоям.
IT>Всё остальное вариации на тему. Хотя, конечно, иногда бывает, что за деревьями леса не видно.

Вы на название топика поглядите? OQ, ну еще Spec упоминались. А если так (упрощенно)

PL:
@someModel.SomeMessage

Сontroller:
someModel.SomeMessage = this._messageService.GetByUserQuery(someUserInput.Query);
...
return View(someModel);

BL:
// валидация
IEnumerable<int> indexes = this.GetMessageIndex(someUserData);
// тут выбор и создание QueryObject по списку индексов
someMessage = dal.ExecuteQuery(selectedQueryObject);
return someMessage;

DAL:
// тут формируется и выполняется запрос к БД на основании переданного QueryObject
// по сути обертка над ORM с учетом особенностей заданного для данного DAL типа хранилища
return message;

Как видите каждый занят своим делом:
PL — показывает
C — обработка user input и отправка результата обратно пользователю
BL — содержит логику
DAL — просто бегает в базу

Со Spec даже веселее было бы, т.к. для Spec можно использовать логические выражения. По сути BL бы строил запрос, оперируя терминами решаемой задачи.

Кстати, в общем случае (если в DAL нет преобразований) это позволяет запихать DAL в отдельные библиотеки (для разных типов хранилища, но реализующие один и тот же интерфейс) и просто через NuGet подключать к проекту. В самом проекте пишутся и тестируются только QO/Spec.

IT>Впрочем, мы можем посмотреть на твой код и решить. Но ты видимо очень сильно стесняешься его показать.

Не вижу в этом необходимости. Тем более, что при желании можно доколупаться до любого кода. Так что я не сомневаюсь что объем вашего "фи" в отношении его будет ограничен только фантазией и свободным временем. Можете начать c "а почему UI не в BL"? :D (как тут уже было http://www.rsdn.ru/forum/design/5049674.1

Автор: IT
Дата: 30.01.13

)

IT>>>Посмотри выше по ветке.
Doc>>Не нашел. Укажите.
IT>Нет никакого желания перелапачивать весь топик.

Тогда постарайтесь ваши фантазии держать при себе.

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

IT>>Что-то я всё больше и больше убеждаюсь, что у кого-то из нас двоих, но не у меня, либо сплошная каша в голове, либо проблемы с терминологией.
Doc>MVC отделяет PL и BL (которая по сути тут M) через C.

О как! Теперь никаких сомнений — каша.

Doc>Ваша версия?

Моя версия такая. Разработка GUI имеет одну фундаментальную проблему. В одном месте у нас находится три составляющих GUI: визуальные компоненты, модель отображаемых данных и контроль состояния всего этого барахла. Смешивание всего этого дела даёт нам умножение сложности всех составляющих. В результе линейное наращивание функционала приводит к экспоненциальному увеличению сложности всего решения. Задача семейства (а это не один паттерн, а целое семейство) MVC паттернов развести все три составляющие по углам и по максимуму устранить или хотя бы ослабить между ними связи.

Работу с BL MVC паттерны не определяют, что вности определённую путаницу. Её пихают/вызывают то из модели, то из контроллера. В последнее время такую логику всё чаще прикомандировывают к контроллеру.

Doc>Хотя вы уже в BL UI включали (и потом неумело отдувались).

Что значит отдувался? Я пишу всю логику в контроллерах и ни секунды не сомневаюсь, что это правильно. Если ты под UI понимаешь все состовляющие MVC паттерна, то да, моя логика в UI, кроме, конечно, компонент, которые используются повторно. Но это не суть.

IT>>Всё остальное вариации на тему. Хотя, конечно, иногда бывает, что за деревьями леса не видно.
Doc>Вы на название топика поглядите? OQ, ну еще Spec упоминались. А если так (упрощенно)

Я же говорю — вариации на тему.

Doc>Как видите каждый занят своим делом:
Doc>PL — показывает
Doc>C — обработка user input и отправка результата обратно пользователю
Doc>BL — содержит логику
Doc>DAL — просто бегает в базу

Тут настоящим делом заняты только PL и C. Остальное архитектурные (или как теперь модно говорить задчиские) излишества. QO выкидываем на йух. BL и DAL объединяем и переносим в C. Код сокращается в пять раз, решение упрощается, все пьют шампанское.

Doc>Со Spec даже веселее было бы...

Это точно.

IT>>Впрочем, мы можем посмотреть на твой код и решить. Но ты видимо очень сильно стесняешься его показать.
Doc>Не вижу в этом необходимости.

Кто бы сомневался.

IT>>Нет никакого желания перелапачивать весь топик.
Doc>Тогда постарайтесь ваши фантазии держать при себе.

При чём тут фантазии. Такие заявления сложно забыть. Я бы и топик перелопатил, если бы наша беседа имела характер не "имею мнение хрен оспоришь", а "есть мнение давайте обсудим".

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

IT>О как! Теперь никаких сомнений — каша.

После этого вашего сообщения я вот так про вас думаю.

IT>Моя версия такая. Разработка GUI имеет одну фундаментальную проблему. В одном месте у нас находится три составляющих GUI: визуальные компоненты, модель отображаемых данных и контроль состояния всего этого барахла. Смешивание всего этого дела даёт нам умножение сложности всех составляющих. В результе линейное наращивание функционала приводит к экспоненциальному увеличению сложности всего решения. Задача семейства (а это не один паттерн, а целое семейство) MVC паттернов развести все три составляющие по углам и по максимуму устранить или хотя бы ослабить между ними связи.

А если много умных слов заменить на суть... останется разделение BL и PL (здесь L не layer, а Logic).

IT>Работу с BL MVC паттерны не определяют, что вности определённую путаницу. Её пихают/вызывают то из модели, то из контроллера. В последнее время такую логику всё чаще прикомандировывают к контроллеру.

Ага, и при этом даже для "пихают в контроллер" вывели anti-pattern Fat Controllers.

Doc>>Хотя вы уже в BL UI включали (и потом неумело отдувались).
IT>Что значит отдувался? Я пишу всю логику в контроллерах и ни секунды не сомневаюсь, что это правильно.

Ну вот дошли до Fat Controllers. И эти люди говорят что я не понимаю MVC
Кстати, Controller это у вас выходит BL?

IT> Если ты под UI понимаешь все состовляющие MVC паттерна, то да, моя логика в UI, кроме, конечно, компонент, которые используются повторно. Но это не суть.

Под UI я понимаю V+C (т.к. С имеет прямое отношение к user input).
А вот BL тут в M.

У вас же C получается "и ваши и нашим", он и от юзера данные получает и BL тянет.

IT>Тут настоящим делом заняты только PL и C. Остальное архитектурные (или как теперь модно говорить задчиские) излишества. QO выкидываем на йух. BL и DAL объединяем и переносим в C. Код сокращается в пять раз, решение упрощается, все пьют шампанское.

Т.е. по сути сказать нечего? Напоминаю вопрос был не "что можно тут поменять", а "где тут дублирование кода и проброс вызовов". Архитектуру оставьте в стороне.

IT>При чём тут фантазии. Такие заявления сложно забыть.

Т.е. я вам ссылкой показал где у вас UI в бизнес-логике. А вы не можете показать якобы мое утверждение. Вывод — у вас развитое воображение.

IT> Я бы и топик перелопатил, если бы наша беседа имела характер не "имею мнение хрен оспоришь", а "есть мнение давайте обсудим".

Так не ведите себя так.