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

A>Приблизительно исходя из тех же соображений люди оформляют страховку.

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

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

kuj>И какой смысл Вы вкладываете в информацию?

Огромный.

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

С>>Информация по определению своему бессмысленной быть не может.
C>Может, причем элементарно.

1. Не желаю спорить в этом ключе. Вернёмся к нашим баранам: помойму, необходимо стремиться к тому, чтобы наша информация на любом из уровней оставалась таковой. И в первую очередь об этом заботится СУ этой БД, сохраняя ссылочную и структурную целостность и т.п. Я не прав?
2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

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

С>>>Информация по определению своему бессмысленной быть не может.
C>>Может, причем элементарно.

С>1. Не желаю спорить в этом ключе. Вернёмся к нашим баранам: помойму, необходимо стремиться к тому, чтобы наша информация на любом из уровней оставалась таковой.

Каковой таковой?

С>И в первую очередь об этом заботится СУ этой БД, сохраняя ссылочную и структурную целостность и т.п. Я не прав?

СУБД это склад — хранилище информации. Да, естественно в задачи СУБД входит обеспечение целостности информации, которую она хранит.

С>2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

Информация в "голом виде" обычно не представляет никакой пользы.

Пример: вы открываете морозильную камеру и видите там кусок замороженного сырого мяса. Станете ли Вы его грызть в таком вот виде?

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

kuj>>И какой смысл Вы вкладываете в информацию?

С>Огромный.

И какой же смысл Вы вкладываете в слово 'Огромный'. Что является мерой?

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

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

Это ты не прав, страховщики тоже каждый месяц надоедают.
Я не говорю что такие манипуляции надо проводить всегда, но для меня очевидно, что объекту-пользователю свойства добавят с очень большой вероятностью, а объекту-накладной свойства добавят с практически нулевой вероятностью.

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

С>2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

Зачем все сразу сводить к пользователю? Приложения это не только формочки и кнопочки! В конце концов, существуют серверные приложения, которые занимаются обработкой данных, но не имеют дел с визуализацией и взаимодействие с пользователем, их работу пользователь вообще не видит или видит опосредованно, через изменения в системе.

Лично для меня при проектировании всегда первична модель данных и бизнес-логика, т.е. адекватное и воспринимаемая человеком модель проблемной области (без привязки к ЯП). Представление объектов модели в конкретном хранилище будь-то субд, объектная база, xml, обычные файлы это вторично. Схема БД — это не информационная модель, а это способ описать отображение этой модели на логические и физические особенности органиации и представления информации в конкретном типе хранилища. Так же как и классы Java, это отражение предметной области средствами языка. Так уж сложилось, что мне, работая в java, при реализации бизнес-логики проще абстрагироваться от физических особенностей хранилища данных, чем если бы я это делал на ХП, поэтому у меня схема БД создается уже после написания классов. Возникает лишь вопрос выбора адекватного способа хранения данных, и не всегда это будет РСУБД.
Если не удается адекватно представить модель данных в хранилище, и способ хранения начинает диктовать изменения в самой модели, стоит подумать о правильности выбора.

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

kuj>И какой же смысл Вы вкладываете в слово 'Огромный'. Что является мерой?
Огромность.

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

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

Хм, не вижу таких задач. Есть примеры?

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

A>Я не говорю что такие манипуляции надо проводить всегда, но для меня очевидно, что объекту-пользователю свойства добавят с очень большой вероятностью, а объекту-накладной свойства добавят с практически нулевой вероятностью.

Кто добавит?

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

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

A>>смотрел это

Автор: Aviator
Дата: 24.09.07

?

K>Да, смотрел, спасибо большое. Но хотелось бы примеры кода (желательно не по 2 строчки) со всех слоев, чтобы увидеть цепочку и понять общую логику, вот например в своем вопросе я привел примеры и думаю абсолютно всем понятно как я строю свое приложение. Вот и мне (и думаю не только мне) хотелось быть понять как вы строите свои приложения (и увидеть это на примерах а не абстрактных выражениях). Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"? Я думаю что в принципе я задал вполне конкретный вопрос, — показать примеры с разных слоев, чтобы можно было понять как вы строите свои приложения. Надеюсь кто-то отвлекется от спора и уделит несколько минут на это.

Присоединяюсь к вопросу.
Что вы человека всякой абстракцией да литературой грузите
Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
Можно же наверное в двух словах показать, как это выглядит У ВАС?


Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага

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

bnk>Присоединяюсь к вопросу.
bnk>Что вы человека всякой абстракцией да литературой грузите
bnk>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>

bnk>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>

Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

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

kuj>Каковой таковой?
Информацией.

kuj>Информация в "голом виде" обычно не представляет никакой пользы.
Согласен. Но я клоню к тому, что удалив ПО, БД должна сохранить модель предметной области, а не отношение классов, которые мы спроектировали в процессе разработки ПО.

kuj>Пример: вы открываете морозильную камеру и видите там кусок замороженного сырого мяса. Станете ли Вы его грызть в таком вот виде?
Ну, это будет зависеть от степени оголодания.

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

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

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

С>Хм, не вижу таких задач. Есть примеры?

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

"Queries for historical data, replete with time ranges and roll ups and arbitrary time zone conversions are difficult in a relational database. Compositions of those rules are even more difficult. This is a problem compounded by the free nature of relational systems themselves. Many relational systems are often not modelled correctly with respect to time series data."

http://en.wikipedia.org/wiki/Time_series_database

bnk>>Присоединяюсь к вопросу.
bnk>>Что вы человека всякой абстракцией да литературой грузите
bnk>>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>>

bnk>>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>>

MC>Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

А можно и я присоединюсь? 300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

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

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

kuj>>Каковой таковой?
С>Информацией.

kuj>>Информация в "голом виде" обычно не представляет никакой пользы.
С>Согласен. Но я клоню к тому, что удалив ПО, БД должна сохранить модель предметной области, а не отношение классов, которые мы спроектировали в процессе разработки ПО.

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

К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

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

A>>Я не говорю что такие манипуляции надо проводить всегда, но для меня очевидно, что объекту-пользователю свойства добавят с очень большой вероятностью, а объекту-накладной свойства добавят с практически нулевой вероятностью.
IT>Кто добавит?

Ну вот изменилось ТЗ (добавилась/изменилась функциональность) и кто-то (скажем, Архитектор, хотя не суть) добавил. Вот хороший был пример с секретным вопросом для восстановления доступа. В моей схеме БД вообще не затрагивается, даже DAL может не затрагиватся если оперирует только с коллекцией Dictionary<string, string> Properties. А так, пришлось бы столбец добавлять.

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

T>Почему я и говорю, что модель данных предметной области != схема БД.

Правда, модель данных предметной области != иерархия классов. Суть же мысли в том, чтобы не играть в испорченный телефон при построении БД.

модель данных предметной области -> иерархия классов -> схема БД.

T>К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

Hibernate как и любая ORM это обощённое средство. Оно ничего не знает о смысле данных, только о структуре.

Вот пример из реальной жизни:
Была табличка с пользователями Users

ID	Login	Password	FirstName	LastName	DateOfBirth
1	admin	...	John	Doe	01/02/1972
2	user	...	Mary	Smith	03/04/1981

которую постоянно меняли. Когда это надоело переделали так
Users

ID	Login	Password
1	admin	...
2	user	...

UserProperties

ID	Name	Value
1	FirstName	John
1	LastName	Doe
1	DateOfBirth	01/02/1972
2	FirstName	Mary
2	LastName	Smith
2	DateOfBirth	03/04/1981

Таблицы с тех пор больше не перестраивались, наступило временное счастье.
Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.

Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД. Пользователь БД не знает одна у него таблица хранит сущность (в данном случае User) или она разбросана по нескольким таблицам. Более того, при изменении переписывается ХП, но не тот, кто её использует. Переносить это выше, в DAL, не разумно так как у нас особенности структуры БД теперь светятся в двух разных местах (на SQL — схема, на Java/C#/C++ — запросы) на двух разных языках и это надо регулярно синхронизировать.

Иногда, на простых данных ORM действительно выдают что-то близкое идеалу. Часто, на не очень сложных данных, ORM выдают что-то относительно приемлемое. Но стоит продумать схему БД как следует, чтобы это была действительно хорошая схема, а не тормоз или монолит и всё что нагенерировали ORM приходится выкидывать. Вот потому я и считаю, что действительно перспективным и правильным является отображать Relational в Object, а не наоборот как сейчас и поступают.

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

kuj>>>а так же с прицнипами DDD.

A>>Кстати вот их то я совсем не догнал

kuj>Если в кратце, то DDD подход упрощает тестирование за счет максимальной изоляции уровня домена от уровня data maping (DAL в простонародии).

kuj>Для этих целей, например, используется паттерн Репозиторий (Repository), который выступает посредником между слоями. Такие репозитории можно размещать в отдельных сборках, что еще более упрощает unit-тестирование.

kuj>Кроме того еще одним вариантом есть использование IoC-контейнеров (мы используем Spring и Castle Windsor).

kuj>В итоге не имеем проблем с TDD подходом для кодирования на весьма большом проекте за исключением вполне естественных проблем на data maping уровне.
C репозитарием много непоняток. Писать кучу функций типа
IList<Order> GetOrdersByDateAndCustomer()
со всеми возможными комбинациями, которых может быть прилично+ новые подятся постоянно не очень хочеться. Постепенно приходим к осознанию необходимости Query object. А писать самому query object неразумно, лучше уж тогда задействовать средства того же хибернета. Так что изоляцию от полная изоляция от сторонних средств и персистентного слоя нет. Плюс коллекции хибернета нарушают PI.

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

K>А можно и я присоединюсь? 300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

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

Итак, у нас есть обработчик кнопки Это Presentation Layer. Не важно Model-View-Controller или Document-View у тебя всегда есть нечто, что надо дёрнуть: Model или Document. В первом случае обработчик кнопки это View, во втором — controller. Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом. Это просто некоторые абстракции, разделяющие функциональность удобным образом. Надо понять что есть в твоём приложении Document. Пусть название не смущает, речь не о чём-то что печатается, а о сущностях, которыми оперирует приложение. Например, для программы учёта трафика Document будет (может быть) совокупностью пользователей, сетевых интерфейсов, замеров расхода трафика, таблиц соответствия пользователей IP адресам в момент времени. Вся эта информация будет представлена в виде объектов некоторых классов — бизнес объектов. Если у тебя приложение содержит одно звено (tier), то есть большой соблазн запихать бизнес-логику в обработчик кнопки. Очень желательно всё таки сдержаться и выделить всю логику относящуюся к обработке информации, но не отображению в бизнес-объекты. Скажем, если вернуться к примеру выше, то проверка корректности введённого IP адреса (что частей четыре и все они меньше, чем 256) это задача Presenation Layer и, хотя я бы написал валидатор, особой трагедии в том, что подобная проверка находится в обработчике кнопки ОК нет. А вот проверка что IP адрес соответствует какому-либо пользователю (получение спска пользователей, которым соответствует IP адрес) это уже задача обработки информации, а не отображения и её надо выделять в Business Logic Layer. Если у тебя многозвенная архитектура (multi-tier, клиент-сервер, трёзвенка), то сущесвенная часть Business Logic может располагатся не на клиенте (последнее звено), а выше. Разговор о том как, где и что делать долгий, сложный и выходит за рамки сообщения форума. Business Logic Layer работает с бизнес-объектами, но не их постоянным хранилищем. То есть сохранять список пользоватейлей в файл Business Logic не умеет. Эти задачи выделяются в Data Access Layer (в multi-tier он обычно в последнем звене, хотя могут быть и промежуточные хранилища служащие разным целям, например, кешированию). Именно Data Access Layer занимается чтением данных из хранилища (файл, БД, удалённое хранилище с доступом по HTTP, и т.д.) и записью их обратно. В случае одного звена DAL отдаёт и принимает сразу BO (Business Objects) с которыми приложение и работает. В случае нескольких звеньев DAL может выдавать DTO (Data Transfer Objects) задача которых — это перенос структурированной информации между звеньями. Если DTO и BO очень похожи, то бывает в качестве BO используют DTO реализуя логику во внешних классах-манипутяторах. Это имеет то преимущество, что нет переноса информации из DTO в BO и обратно. Недостаток — большая угроза потери инкапсуляции.

Как-то сумбурно вышло, спрашивай если что, какашки всё равно закончились.