Здравствуйте, C0s, Вы писали:
C0s>странно, что у меня такой проблемы нет. для меня hibernate — это инструмент реализации БЛ, связанной с необходимостью манипулировать и извлекать данные в БД. C0s>выше БЛ (презентационному уровню, комманд-лайн утилитам выполнения ночных задач, методам интеграции с внешними системами) наличие hibernate не видно в принципе. все эти субстанции видят только БЛ-API и связаны с ним только через структуры данных, под это API написанные
Это легко обоъясняется. Скорее всего ты хорошо знаком с хибернейтом и чётко следуешь его правилам при построении своей архитектуры. В резултате у вас получается полная идилия
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
C0s>>странно, что у меня такой проблемы нет. для меня hibernate — это инструмент реализации БЛ, связанной с необходимостью манипулировать и извлекать данные в БД. C0s>>выше БЛ (презентационному уровню, комманд-лайн утилитам выполнения ночных задач, методам интеграции с внешними системами) наличие hibernate не видно в принципе. все эти субстанции видят только БЛ-API и связаны с ним только через структуры данных, под это API написанные
IT>Это легко обоъясняется. Скорее всего ты хорошо знаком с хибернейтом и чётко следуешь его правилам при построении своей архитектуры. В резултате у вас получается полная идилия
если дать крен в философию, то можно сравнить с машиной. с одной стороны, чтобы ехать надо чётко понимать и следовать определенным законам, но с другой стороны — это всего лишь инструмент перемещения...
если же продолжать рассуждать о технической стороне подхода, то для меня гораздо менее важно, насколько я буду отвязан снизу уровня БЛ от ORM/БД/DAO/всё-что-угодно, и, наоборот, более важно зафиксировать интерфейсы и структуры данных БЛ, которые видны вышележащему слою.
Здравствуйте, IT, Вы писали:
C0s>>ps. ессно, наличие такой фичи имхо следует воспринимать как наличие спецподушки безопасности, что если вдруг так сложится, что что-то не ляжет по каким-то критериям (быстродействия, быстроприкручивания и т.п.) в стройную картину hibernate-подхода, то всегда остаётся возможность низкоуровневого доступа к данным (на свой риск получить трудноподдерживаемый код) IT>Т.е. фактически такая возможность является документированной дыркой в заборе, через которую можно туда сюда таскать неучтённые данные. Я правильно понимаю?
В Hibernate при желании можно вообще почти все переписать — там внутри архитектура построена на событиях. В частности, Google так и сделал для добавления поддержки горизонтального разделения данных.
Здравствуйте, IT, Вы писали:
C>>В Hibernate можно кастомизировать все этапы жизни — ты можешь загрузить объект руками через SQL и воткнуть его в сессию при желании, можешь выдирать объекты из сессии, обновлять и т.п. IT>Дело в том, что мне вообще сессия не нужна.
Эээ... А откуда у тебя будет соединение с БД браться? А сохранение идентичности у тебя поддерживается?
Кстати, в Hibernate есть легковесная сессия, которая фактически просто оборачивает соединение с БД и вообще не делает ничего лишнего.
IT>Я без неё прекрасно обхожусь. При этом что касается быстродействия, расширяемости, гибкости и простоты кода, то любой хибернейт уплачется самыми горючими слезами.
По сравнению с BL Toolkit? Прости, но Hibernate удобнее.
Здравствуйте, IT, Вы писали:
C>>Однако, слой бизнес-логики все равно в нормальном приложении присутствует. Так как приложения, которые просто работают интерфейсами к таблицам в базе, я вообще серьезными приложениями не считаю. IT>Это уже пенисометрия пошла.
Почему? Ну не считаю я простые интерфейсы к БД чем-то заслуживающим внимания. Да, они нужны, но мне абсолютно неинтересны — со времен Delphi тут уже все осовено.
IT>А если так, то я, например, считаю, что 80% логики в 80% "серьёзных" приложений являются результатом кривого дизайна, жестокого хардкода и затычек, необходимых для выкривления кривизны первого и второго.
Например, для бухгалтерии теперь вычисление зарплаты (с учетом overtime, праздников, отпусков, больничных) — это следствие кривизны, так как на модель данных плохо отображается?
Здравствуйте, Cyberax, Вы писали:
C>Эээ... А откуда у тебя будет соединение с БД браться?
Из кеша ADO.NET.
C>А сохранение идентичности у тебя поддерживается?
Это когда два разных запроса одних и тех же данных возвращают один и тот же объект? Я этими глупостями уже не занимаюсь. Такой дипазал, что в нём больше проблем, чем преимуществ.
C>Кстати, в Hibernate есть легковесная сессия, которая фактически просто оборачивает соединение с БД и вообще не делает ничего лишнего.
Ещё одна дырка в заборе?
IT>>Я без неё прекрасно обхожусь. При этом что касается быстродействия, расширяемости, гибкости и простоты кода, то любой хибернейт уплачется самыми горючими слезами. C>По сравнению с BL Toolkit? Прости, но Hibernate удобнее.
Да ради бога, я разве против Нравится, пользуйся. Не нравится, не пользуйся. По мне так ни то, ни другое не является идеалом. Cегодня вообще смотреть нужно в сторону dsl'ей.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
IT>>Это уже пенисометрия пошла. C>Почему?
Потому что при желании большинство задач можно свести к интерфейсу к БД, а можно любую самую простую реализовать кучей непонятно что и зачем делающего кода.
C>Ну не считаю я простые интерфейсы к БД чем-то заслуживающим внимания. Да, они нужны, но мне абсолютно неинтересны — со времен Delphi тут уже все осовено.
IT>>А если так, то я, например, считаю, что 80% логики в 80% "серьёзных" приложений являются результатом кривого дизайна, жестокого хардкода и затычек, необходимых для выкривления кривизны первого и второго. C>Например, для бухгалтерии теперь вычисление зарплаты (с учетом overtime, праздников, отпусков, больничных) — это следствие кривизны, так как на модель данных плохо отображается?
Есть много путей решения, всё зависит от требований. А вот ответь ты мне. Что насчёт ввода табеля, ввода праздников, отпусков и больничных, новых работников и изменения их параметров. Это уже не зарплата, или здесь у тебя тоже супер навороченная бизнес логика? А может это всё-таки те самые 80% любой задачи?
C>А еще есть BPM-системы — это тоже кривость?
К моему стыду, не знаю что это такое.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Это уже пенисометрия пошла. C>>Почему? IT>Потому что при желании большинство задач можно свести к интерфейсу к БД, а можно любую самую простую реализовать кучей непонятно что и зачем делающего кода.
Я бы сказал, что при желании большинство задач можно на 80%-90% свести к интерфейсу с БД.
C>>Например, для бухгалтерии теперь вычисление зарплаты (с учетом overtime, праздников, отпусков, больничных) — это следствие кривизны, так как на модель данных плохо отображается? IT>Есть много путей решения, всё зависит от требований. А вот ответь ты мне. Что насчёт ввода табеля, ввода праздников, отпусков и больничных, новых работников и изменения их параметров. Это уже не зарплата, или здесь у тебя тоже супер навороченная бизнес логика? А может это всё-таки те самые 80% любой задачи?
Так я не возражаю. Я только говорю, что обычно эта часть не представляет особого интереса. Там все по большей части достаточно просто и вполне хватает средств, которые существуют уже лет 10.
C>>А еще есть BPM-системы — это тоже кривость? IT>К моему стыду, не знаю что это такое. http://en.wikipedia.org/wiki/Business_Process_Management
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, IT, Вы писали:
IT>>Cегодня вообще смотреть нужно в сторону dsl'ей.
ДГ>Можно ссылочку на "что это такое?" ДГ>Спасибо.
Здравствуйте, C0s, Вы писали:
C0s>моими DTO никакой ORM не управляет, они рождаются на уровне БЛ
Во. А я толкую о том, что рождаться они должны на уровне DAL ибольше ни во что не трансформироваться.
Здравствуйте, Cyberax, Вы писали:
C>Сразу видно плохое влияние MS
Что же в нем плохого?
C>Эээ... Как одним из доводов за использование DAO была возможность прозрачно использовать разные виды источники данных. Или я чего-то не понимаю?
Это не цель, это то, что получается само.
C>"Наружу" это куда? На клиент — несомененно (кроме особых случаев). В вот бизнес-логику, ИМХО, смысла нет изолировать.
Именно бизнес-логику и есть смысл изолировать. Собственно об этом и речь.
C>?? То есть тебе в бизнес-слое пофиг на транзакции?
На транзакции в терминах БД? Конечно пофиг.
C> А если для определенного алгоритма потребуется особый уровень изоляции?
Уровень изоляции — это забота DAL, для бизнес-слоя транзакция всегда должа быть Serializable, никаких особых уровней там быть не должно.
C>Так как в анекдоте — Hibernate получается.
Не получается, гибернейт все равно заставляет думать об источнике конкретного объекта и его зависимостях.
C>Не достаточно сильноразные источники используешь, видимо.
Мне хватает.. (
C>А что делаешь вместо CRUDа?
Пишу свой DAL под мои задачи.
C>Почему уже обычные?
Потому что я их такими сделал.
C>И что ты собираешься делать с зависимыми объектами?
Зависимыми от чего?
Здравствуйте, IT, Вы писали:
IT>Что-бы воплотить её в жизнь, нужно стараться, тратить на это время и ресурсы, специально подбирать инструменты и затачивать архитектуру. Бесплатно такая сказка не даётся.
Угу, но это уже другой вопрос.
IT>ORM сегодня уже вообще никого не должен волновать. Всё уже мильён раз жёвано пережёвано.
Меня-то он уже давно не волнует.. )
IT>В принципе нет. У этих библиотек абсолютно разный API.
Но мой-то код будет работать не с этим API, а с моим собственным, который будет транслировать все вызовы в API конкретной системы.
IT>BL в большинстве приложений на 90% вообще должен умереть. Должна остаться модель данных, отображённая на БД и запросы к этой модели. В общем, что-то похожее на хибернейт, только развернуть эту избушку надо к лесу задом, а не так как сейчас.
Велкам то Entity Framework и LINQ 2 Entity.. =)
IT>Ты попробуй сначала, потом обсудим.
Ну яж говорю, для веб и вин пробовал, тоже малопохожие конструкции, но получилось довольно не плохо...
IT>Это я понял. Я не согласен с тобой в том, что гвозди и библиотеки — это зло. От этого никуда не денешься.
Хорошо. Если ближе к теме — мне конкретно не нравятся гвозди гибернейта.
Здравствуйте, C0s, Вы писали:
C0s>я считаю, что лучше так, чем объяснять заказчику, что "мы не стали бороться со сбоями вообще, в угоду нашим представлениям о программировании, а также из-за общего пофигизма в ситуации, когда API к Legacy-системе не поддерживает транзакции"
Ну что опять за демагогия?
Разница в том, что в моем случае BL выглядит так:
begin_tran
Method1()
Method2()
commit
А в твоем :
if (Legacy1())
обрабатываем ситуацию с тем что L1 транзакцию не поддерживает
else if (Legacy2())
обрабатываем ситуацию с тем что L2 транзакцию поддерживает
но ни так как нам надо
else if (Native())
делаем просто вызов Native(), но опят-таки в явной транзакции
else — еще что-нибудь...
Я даже не буду подкалывать, что твой код якобы не заработает. Допустим, что и в том и в другом случае работать все будет одинаково... Только вот понять, чем собственно система занимается в конкретном случае и выкинуть обращение к легаси коду, когда он будет переписан, в первом случае, сдается мне, будет существенно проще.
Здравствуйте, Cyberax, Вы писали:
C>То есть у тебя-таки бизнес-слой будет адаптирован для нетранзакционного DALа?
Да ну нет же. Связь в обратную сторону развернута — DAL будет адаптироваться под нужды BL.
Здравствуйте, IB, Вы писали:
IT>>BL в большинстве приложений на 90% вообще должен умереть. Должна остаться модель данных, отображённая на БД и запросы к этой модели. В общем, что-то похожее на хибернейт, только развернуть эту избушку надо к лесу задом, а не так как сейчас. IB>Велкам то Entity Framework и LINQ 2 Entity.. =)
Ну да. Монстрик похлеще хибернейта.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
IT>>Потому что при желании большинство задач можно свести к интерфейсу к БД, а можно любую самую простую реализовать кучей непонятно что и зачем делающего кода. C>Я бы сказал, что при желании большинство задач можно на 80%-90% свести к интерфейсу с БД.
Можно и так.
C>Так я не возражаю. Я только говорю, что обычно эта часть не представляет особого интереса. Там все по большей части достаточно просто и вполне хватает средств, которые существуют уже лет 10.
Здравствуйте, IT, Вы писали:
C>>Так я не возражаю. Я только говорю, что обычно эта часть не представляет особого интереса. Там все по большей части достаточно просто и вполне хватает средств, которые существуют уже лет 10. IT>10 лет назад немеряно рулили двузвенки. Предлагаешь назад в будущее?
Вообще говоря, для непосредственного показа данных "псевдодвухзвенки" и сейчас рулят.
C>>http://en.wikipedia.org/wiki/Business_Process_Management IT>И какие у нас тут особенные проблемы?
Скажу так — без выделения сущностей (что-то тита ORM) там все очень плохо. Но это уже другой флейм.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
