Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>Здравствуйте, Andrbig, Вы писали:
A>>Здравствуйте, Daimond, Вы писали:
D>>>А все-таки так никто и не дал ответа на мой основной вопрос. D>>>Неужели у все екзешники называются "MyApplication.Forms.exe" ???
A>>Нет, просто datalayer не называется MyApplication.dll. Какой это нахрен application, если это datalayer?
DD>Это не DataLayer, а бизнес-логика + слой доступа к данным. Это и есть Application. А морд у приложения может быть много — морды это не Application.
Это подход программиста. Подход же юзера: "кого пущаю, то и программа" и плевал он на бизнес-логику и прочие программистские вещи. Так что для него есть приложение — это MyApplication.exe и куча мусора рядом.
Ты сначала выбери точку зрения, от этого зависит кого ты как назовешь.
Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>"правильно — это чтобы DataLayer знал (зависел от) о Domain" != DD>"бизнес-логика ... обращается к da-слою для загрузки/сохранения сущностей."
Я имел в виду "Domain никогда сам не вызывает сохранающий/загружающий его код."
L>>Датасет.
DD>ДатаСет? В датасете можно воспроизвести структуру БД, и команды для модификации таблиц, но в большинстве случаев структура бизнес-логики отличается от структуры БД. Так что появляется слой (типа, DataLayer)Ю который эти структуры в соответствие приводит. И он в курсе как о БД, так и о Бизнес-логики. Так что один только Датасет, по моему мнению, всех проблем не решит.
Извини, я не знаю что такое структура бизнес-логики, поэтому не могу прокомментировать твои слова.
A>>>Нет, просто datalayer не называется MyApplication.dll. Какой это нахрен application, если это datalayer?
DD>>Это не DataLayer, а бизнес-логика + слой доступа к данным. Это и есть Application. А морд у приложения может быть много — морды это не Application.
A>Это подход программиста. Подход же юзера: "кого пущаю, то и программа" и плевал он на бизнес-логику и прочие программистские вещи. Так что для него есть приложение — это MyApplication.exe и куча мусора рядом.
A>Ты сначала выбери точку зрения, от этого зависит кого ты как назовешь.
Согласен. Вот и пытаюсь объединить эти точки зрения, что бы "и нашим и вашим".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>>"правильно — это чтобы DataLayer знал (зависел от) о Domain" != DD>>"бизнес-логика ... обращается к da-слою для загрузки/сохранения сущностей."
L>Я имел в виду "Domain никогда сам не вызывает сохранающий/загружающий его код."
Почему? Что в этом не логичного? Если у бизнес-объекта есть дочернии элементы (тоже бизнес-объекты), то вполне логично, если он САМ их сохранит. А они сохранят свои дочернии элементы (тоже бизнес-объекты) и тд.
L>>>Датасет.
DD>>ДатаСет? В датасете можно воспроизвести структуру БД, и команды для модификации таблиц, но в большинстве случаев структура бизнес-логики отличается от структуры БД. Так что появляется слой (типа, DataLayer)Ю который эти структуры в соответствие приводит. И он в курсе как о БД, так и о Бизнес-логики. Так что один только Датасет, по моему мнению, всех проблем не решит.
L>Извини, я не знаю что такое структура бизнес-логики, поэтому не могу прокомментировать твои слова.
Я имел ввиду модель предметной области по Фаулеру.
Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>Почему? Что в этом не логичного? Если у бизнес-объекта есть дочернии элементы (тоже бизнес-объекты), то вполне логично, если он САМ их сохранит. А они сохранят свои дочернии элементы (тоже бизнес-объекты) и тд.
Тут не применимо понятие логично/нелогично. Просто есть разные подходы. Либо бизнес-логика в бизнес-объектах (как предлагаешь ты), либо она вне них (a-la entity/session beans).
L>>Извини, я не знаю что такое структура бизнес-логики, поэтому не могу прокомментировать твои слова.
DD>Я имел ввиду модель предметной области по Фаулеру.
Так что тебе мешает иметь схему датасетов отличной от схемы базы данных?
Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>Здравствуйте, Andrbig, Вы писали:
A>>>>Нет, просто datalayer не называется MyApplication.dll. Какой это нахрен application, если это datalayer?
DD>>>Это не DataLayer, а бизнес-логика + слой доступа к данным. Это и есть Application. А морд у приложения может быть много — морды это не Application.
A>>Это подход программиста. Подход же юзера: "кого пущаю, то и программа" и плевал он на бизнес-логику и прочие программистские вещи. Так что для него есть приложение — это MyApplication.exe и куча мусора рядом.
A>>Ты сначала выбери точку зрения, от этого зависит кого ты как назовешь.
DD>Согласен. Вот и пытаюсь объединить эти точки зрения, что бы "и нашим и вашим".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
L>Тут не применимо понятие логично/нелогично. Просто есть разные подходы. Либо бизнес-логика в бизнес-объектах (как предлагаешь ты), либо она вне них (a-la entity/session beans).
Ок.
L>>>Извини, я не знаю что такое структура бизнес-логики, поэтому не могу прокомментировать твои слова.
DD>>Я имел ввиду модель предметной области по Фаулеру.
L>Так что тебе мешает иметь схему датасетов отличной от схемы базы данных?
По жизни, мне ничего не мешает, просто разобраться хочется.
Появляется дополнительный слой где эта связь должна описыватся. Таким образом data-layer = dataset + этот слой. Получается, что datalayer осведомлен о Domain.
Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>Появляется дополнительный слой где эта связь должна описыватся. Таким образом data-layer = dataset + этот слой.
Нет, data-layer — это только сой сохранения/чтения. dataset — это entity-layer
DD>Получается, что datalayer осведомлен о Domain.
Здравствуйте, Dmitriy Dubrovskiy, Вы писали:
DD>Совершенно с тобой согласен. Это тоже вариант. Вполне живучий, но не всегда удобный, тем, что инициатор сохранения в БД является слой Presentation (у тебя AppLayer). Если у тебя сложная бизнес-логика, включающая коллекции, наследование, много всего, и тд., то всю эту структуру должен знать Presentation, чтобы передать все эти объекты DALу для сохранения в БД. Геморойно получается (на сложном примере) и слишком зависимо. Куда проше: пользователь нажал кнопку -> вызывается метод BO.Save() -> бизнес объект сам себя сохраняет со всеми связями и зависимостями. А главное минимальная зависимость между мордами и бизнес-логикой.
Во-первых, инициатором выступает всегда тот уровень, который взаимодействует с пользователем непосредственно. Это либо GUI, либо какой-нить web-service api, если с твоей системой можно работать в обход гуи.
Во-вторых, любая сложность структуры всегда легко скрывается за "фасадом" любой природы:
class AppMainForm .. {
public OnEntitySave(..entity..) {
IFacade facade = // get entity-specific facade instance
facade.save(entity);
}
}
...
class MyBarFacade : IFacade { // "bar"-specific entity facade
public void save(IEntity entity) {
// 1.) get entity-specific DAL object
// 2.) invoke this DAL.save(entity)
}
}
В-третьих, если ты все-таки оставишь как есть, и обекты будут у тебя уметь сами себя сохранять, то подумай, что будет, если нужно будет изменить структуру хранилища? или способ доступа к нему? или добавить доп. способ сохранения? тебе как минимум нужно будет внести изменения во все твои бизнес объекты (а внесение любых изменений в оттестированный и сданный код — это всегда риск, как бы ты не уверял, что "почти ничего не тронул")
В-четвертых и в-главных: ну разве не понятно, что любой компонент должен быть ответственнен только за свою специфическую задачу? и что не нужно в один и тот же компонент или слой впихивать целую кучу работы? Любая функциональность, которая может быть по своей природе расширена однородными операциями, должна быть и оформлена в виде _отдельного_ кода, от которого BO не зависят.
...добавлю: основная задача BO — это "быть самими собой", то есть просто хранить некоторые данные в какой-то структуре, которая может быть использована другими частями/компонентами приложения.
Какой это нахрен application, если это datalayer? 
просто разобраться хочется.
