Уровень данных + уровень бизнес-логики =>
default namespace = MyApplication
соответственно, сборка под именем MyApplication, файл MyApplication.dll
содержит namespace MyApplication.DataLayer и MyApplication.Domain,
является ClassLibrary
Вторая сборка
Формочки + все, что касается GUI =>
default namespace = MyApplication.Forms
соответственно, сборка под именем MyApplication.Forms, файл MyApplication.Forms.exe
При такой структуре получается исполняемый файл "MyApplication.Forms.exe", что вообщем-то не очень красиво, красиво было бы "MyApplication.exe".
Какая структура проектов у вас? Или имя файла "MyApplication.Forms.exe" можно считать приемлемым (вдруг в будущем появится "MyApplication.Console.exe") ?
Переносить точку входа в приложения в первую сборку не правильно, т.к добавит связей между GUI и предметной области, чего хотелось бы избежать.
Называть первую сборку MyApplication.Domain, а вторую MyApplication, как-то не логично. Да и сборок с разными GUI может быть много.
Здравствуйте, NoiseMaker, Вы писали:
NM>Если не нравится автоматически сгенерированное студией имя exe-файла, измени его в настройках проекта. NM>А структура проекта нормальная...
Где? Я могу изменить имя сборки, но если я изменю ее на MyApplication (чтобы у меня имя exe-файла было MyApplication.exe), это будет конфликтовать с моей первой сборкой (как ты помнишь она тоже имеет имя MyApplication). Может я не нашел чего? Как изменить имя exe-файла не меняя имени сборки? А вообще токое правильно???
Здравствуйте, Daimond, Вы писали:
D>Где? Я могу изменить имя сборки, но если я изменю ее на MyApplication (чтобы у меня имя exe-файла было MyApplication.exe), это будет конфликтовать с моей первой сборкой (как ты помнишь она тоже имеет имя MyApplication). Может я не нашел чего? Как изменить имя exe-файла не меняя имени сборки? А вообще токое правильно???
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Daimond, Вы писали:
D>>Где? Я могу изменить имя сборки, но если я изменю ее на MyApplication (чтобы у меня имя exe-файла было MyApplication.exe), это будет конфликтовать с моей первой сборкой (как ты помнишь она тоже имеет имя MyApplication). Может я не нашел чего? Как изменить имя exe-файла не меняя имени сборки? А вообще токое правильно???
L>Разбей Domain и DataLayer на две сборки.
А что это решит?
Уровень Domain должен быть осведомлен об уровне DataLayer, чтобы знать КАК записывать себя в БД. Уровень DataLayer должен быть осведомлен об уровне Domain, чтобы знать ЧТО он должен записать в БД. Конечно, эта связь должна быть минимальна, но она будет. (Выход: использовать промежуточную сборку с интерфейсами, что не во всех проектах окупается). Покажи пример, как выглядит подобное разбиение.
Здравствуйте, Daimond, Вы писали:
D>Уровень Domain должен быть осведомлен об уровне DataLayer, чтобы знать КАК записывать себя в БД. Уровень DataLayer должен быть осведомлен об уровне Domain, чтобы знать ЧТО он должен записать в БД. Конечно, эта связь должна быть минимальна, но она будет. (Выход: использовать промежуточную сборку с интерфейсами, что не во всех проектах окупается). Покажи пример, как выглядит подобное разбиение.
А зачем домену знать о том как его будут сохранять?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Daimond, Вы писали:
D>>Уровень Domain должен быть осведомлен об уровне DataLayer, чтобы знать КАК записывать себя в БД. Уровень DataLayer должен быть осведомлен об уровне Domain, чтобы знать ЧТО он должен записать в БД. Конечно, эта связь должна быть минимальна, но она будет. (Выход: использовать промежуточную сборку с интерфейсами, что не во всех проектах окупается). Покажи пример, как выглядит подобное разбиение.
L>А зачем домену знать о том как его будут сохранять?
Он должен знать, ЧТО СДЕЛАТЬ, ЧТОБЫ СЕБЯ СОХРАНИТЬ.
Грубо говоря, объект предиетной области должен знать, что есть такой DataMapper в пространстве имен DataLayer, у этого DataMapperа есть метод SaveDomainObject(...) и если вызвать DataMapper.SaveDomainObject(this), то это его сохранит. Вот.
Предложи, пожалуйста, архитектуру с разносом DataLayer и Domain по разным сборкам, не используя промежуточную с интерфейсами.
Здравствуйте, Daimond, Вы писали:
D>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, Daimond, Вы писали:
D>>>Уровень Domain должен быть осведомлен об уровне DataLayer, чтобы знать КАК записывать себя в БД. Уровень DataLayer должен быть осведомлен об уровне Domain, чтобы знать ЧТО он должен записать в БД. Конечно, эта связь должна быть минимальна, но она будет. (Выход: использовать промежуточную сборку с интерфейсами, что не во всех проектах окупается). Покажи пример, как выглядит подобное разбиение.
L>>А зачем домену знать о том как его будут сохранять?
D>Он должен знать, ЧТО СДЕЛАТЬ, ЧТОБЫ СЕБЯ СОХРАНИТЬ.
D>Грубо говоря, объект предиетной области должен знать, что есть такой DataMapper в пространстве имен DataLayer, у этого DataMapperа есть метод SaveDomainObject(...) и если вызвать DataMapper.SaveDomainObject(this), то это его сохранит. Вот.
D>Предложи, пожалуйста, архитектуру с разносом DataLayer и Domain по разным сборкам, не используя промежуточную с интерфейсами.
Хм. IMHO, правильно — это чтобы DataLayer знал (зависел от) о Domain, наоборот — неверно. Следовательно, Domain никогда сам не вызывает сохранающий/загружающий его код. Вместо него это делает уровень бизнес-логики (то есть самый Forms.exe в виде обработки user actions).
Здравствуйте, Daimond, Вы писали:
L>>А зачем домену знать о том как его будут сохранять?
D>Он должен знать, ЧТО СДЕЛАТЬ, ЧТОБЫ СЕБЯ СОХРАНИТЬ.
D>Грубо говоря, объект предиетной области должен знать, что есть такой DataMapper в пространстве имен DataLayer, у этого DataMapperа есть метод SaveDomainObject(...) и если вызвать DataMapper.SaveDomainObject(this), то это его сохранит. Вот.
D>Предложи, пожалуйста, архитектуру с разносом DataLayer и Domain по разным сборкам, не используя промежуточную с интерфейсами.
Легко. Entity — тупые как пробка, фактически просто DTO, Вся бизнес-логика сисредоточена в бизнес-слое, который и обращается к da-слою для загрузки/сохранения сущностей.
D>>Предложи, пожалуйста, архитектуру с разносом DataLayer и Domain по разным сборкам, не используя промежуточную с интерфейсами.
L>Легко. Entity — тупые как пробка, фактически просто DTO, Вся бизнес-логика сисредоточена в бизнес-слое, который и обращается к da-слою для загрузки/сохранения сущностей.
Реализовать такое будет возможно, только если дата-слой принимает мета-данные, описывающие КАК сохранить сущности (например, используя NHibernate или подобные мепперы). В противном случае, дата-слой должен знать, что если он принял объект Departament, то должен сохранить поля Name, Code и тд. в соответствующих полях таблицы DEPARTAMENTS, вызвать такие-то хранимки, исполнить такие-то запросы. Кто ему об этом скажет? Либо мета-данные, либо это должно быть в коде DataMappera, а значит слой данных становится зависим от Сущностей бизнес-логики.
Кинь какой-нть пример тупого как пробка Entity (элементарный, конечно) — меня давно эта тема интересует.
Здравствуйте, ika, Вы писали:
ika>Здравствуйте, Daimond, Вы писали:
D>>Здравствуйте, Lloyd, Вы писали:
L>>>Здравствуйте, Daimond, Вы писали:
D>>>>Уровень Domain должен быть осведомлен об уровне DataLayer, чтобы знать КАК записывать себя в БД. Уровень DataLayer должен быть осведомлен об уровне Domain, чтобы знать ЧТО он должен записать в БД. Конечно, эта связь должна быть минимальна, но она будет. (Выход: использовать промежуточную сборку с интерфейсами, что не во всех проектах окупается). Покажи пример, как выглядит подобное разбиение.
L>>>А зачем домену знать о том как его будут сохранять?
D>>Он должен знать, ЧТО СДЕЛАТЬ, ЧТОБЫ СЕБЯ СОХРАНИТЬ.
D>>Грубо говоря, объект предиетной области должен знать, что есть такой DataMapper в пространстве имен DataLayer, у этого DataMapperа есть метод SaveDomainObject(...) и если вызвать DataMapper.SaveDomainObject(this), то это его сохранит. Вот.
D>>Предложи, пожалуйста, архитектуру с разносом DataLayer и Domain по разным сборкам, не используя промежуточную с интерфейсами.
ika>Хм. IMHO, правильно — это чтобы DataLayer знал (зависел от) о Domain, наоборот — неверно. Следовательно, Domain никогда сам не вызывает сохранающий/загружающий его код. Вместо него это делает уровень бизнес-логики (то есть самый Forms.exe в виде обработки user actions).
Здравствуйте, Daimond, Вы писали:
D>А все-таки так никто и не дал ответа на мой основной вопрос. D>Неужели у все екзешники называются "MyApplication.Forms.exe" ???
Нет, просто datalayer не называется MyApplication.dll. Какой это нахрен application, если это datalayer?
Присмотрись внимательнее, это одно и то же мнение.
D>Реализовать такое будет возможно, только если дата-слой принимает мета-данные, описывающие КАК сохранить сущности (например, используя NHibernate или подобные мепперы). В противном случае, дата-слой должен знать, что если он принял объект Departament, то должен сохранить поля Name, Code и тд. в соответствующих полях таблицы DEPARTAMENTS, вызвать такие-то хранимки, исполнить такие-то запросы. Кто ему об этом скажет? Либо мета-данные, либо это должно быть в коде DataMappera, а значит слой данных становится зависим от Сущностей бизнес-логики.
Да, совершенно верно.
D>Кинь какой-нть пример тупого как пробка Entity (элементарный, конечно) — меня давно эта тема интересует.
Здравствуйте, Daimond, Вы писали:
D>А все-таки так никто и не дал ответа на мой основной вопрос. D>Неужели у все екзешники называются "MyApplication.Forms.exe" ???
Не знаю как у всех, но у нас он называется MyApplication.exe.
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Daimond, Вы писали:
D>>А все-таки так никто и не дал ответа на мой основной вопрос. D>>Неужели у все екзешники называются "MyApplication.Forms.exe" ???
A>Нет, просто datalayer не называется MyApplication.dll. Какой это нахрен application, если это datalayer?
Это не DataLayer, а бизнес-логика + слой доступа к данным. Это и есть Application. А морд у приложения может быть много — морды это не Application.
ika>Какая двусторонняя связь? Какие мапперы? Какие метаданные? ika>Расставьте между компонентами правильные зависимости! И все! Нефиг городить.
ika>
ika>BO и DAL компоненты кладешь либо в одну сборку либо в разные (совершенно неважно).
Совершенно с тобой согласен. Это тоже вариант. Вполне живучий, но не всегда удобный, тем, что инициатор сохранения в БД является слой Presentation (у тебя AppLayer). Если у тебя сложная бизнес-логика, включающая коллекции, наследование, много всего, и тд., то всю эту структуру должен знать Presentation, чтобы передать все эти объекты DALу для сохранения в БД. Геморойно получается (на сложном примере) и слишком зависимо. Куда проше: пользователь нажал кнопку -> вызывается метод BO.Save() -> бизнес объект сам себя сохраняет со всеми связями и зависимостями. А главное минимальная зависимость между мордами и бизнес-логикой.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Daimond, Вы писали:
D>>А все-таки так никто и не дал ответа на мой основной вопрос. D>>Неужели у все екзешники называются "MyApplication.Forms.exe" ???
L>Не знаю как у всех, но у нас он называется MyApplication.exe.
)
L>Присмотрись внимательнее, это одно и то же мнение.
"правильно — это чтобы DataLayer знал (зависел от) о Domain" !=
"бизнес-логика ... обращается к da-слою для загрузки/сохранения сущностей."
L>Датасет.
ДатаСет? В датасете можно воспроизвести структуру БД, и команды для модификации таблиц, но в большинстве случаев структура бизнес-логики отличается от структуры БД. Так что появляется слой (типа, DataLayer)Ю который эти структуры в соответствие приводит. И он в курсе как о БД, так и о Бизнес-логики. Так что один только Датасет, по моему мнению, всех проблем не решит.
Здравствуйте, 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? 
просто разобраться хочется.