Уровень данных + уровень бизнес-логики =>
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)Ю который эти структуры в соответствие приводит. И он в курсе как о БД, так и о Бизнес-логики. Так что один только Датасет, по моему мнению, всех проблем не решит.
Какой это нахрен application, если это datalayer? 
