Разрабатывается пакет из ~20 приложений (Suite), 15 из них должны быть web- и win- based, около 6 еще API для сторонних программ. База данных общая.
80% всех приложений будут использовать некоторые общие модели, такие как: Language, Country, UnitOfMeasure, User, Application, Log и т.д. и т.п.
Все приложения 4-ех слойные (DATA ACCESS, DOMAIN, SERVICES, PREZENTATION).
Как лучше организовать сборки? Особенно важно наиболее правильно сделать для приложения, которое будут использовать все другие приложения (Master).
Сам только так вижу...

Suite-Core--Data---IDataContext---IGenericRepository<T>--Domain(shared models)---User---UnitOfMeasure---…-Data.EF---EfDataContext---EfRepositories---Mappings-Data.WCF---WCFDataAccess---WCFRepositories-Framework/Utils--Authentification--Permissions--… Master-Services---UserServices0---UnitOfMeasureServices---…-WebAPI App01-Domain--Model1--…-Services---Services01---…-Presentation--MVC--WebAPI+WPF--…

skyANAТут надо уточнить,Да, уточнить надо :) У меня в таблицах - отдельные солушины, красным - проджекты.

skyANAприложение, которое будут использовать все другие приложения (Master)ну это как и описал - приложение для логгинга, получить шаред справочники, преветь права пользователя... то есть как бы получается не приложение как таковое, а набор сервисов для работы с общими моделями, которые будут использоваться в других приложениях. не делать в каждом новом свою реализацию получения списков всех языков, пользователей, логгинг... или делать?)

skyANAПочему User находится в Suite, а UserService в Masterне знаю, но самому тоже не нравится. лучше юзеров мастер, или мастер в суит? :)

skyANA,

То есть например Апп01 имеет свою домееную модель и логику. Ей чтобы взлететь в виде MVC надо Core, Data.Ef, Utils и MasterSerives (чтобы получить справочник-список стран), что ей встать на Windows надо Core, Data.WCF, Utils, MasterServices и Master WebAPI.
И получается так?

Изначально хотелось Core оставить только для интерфейсов. Потому и образовался этот отдельный мастер с имплементацией.

ну и вопрос сразу возникает - как с domain model и с базой быть?
в Data.EF продублировать модели как ентити соответствующие таблицам бд и туда же какой-нибудь automapper положить, чтобы из DAL получать модели а не таблицы?

skyANAкакой смысл Data и Domain объединять в некий Core?Задача некоего Core - обслуживать аппсы (апп как в понятии пользователя, т.е. MusicStoreWpf, MusicStoreWeb и MusicStoreDalEf - это все один аппликейшин): хандлить ерроры, логить события, думать как и куда положить файлы и как их потом отдать, послать емаил, сообщить текущий часовой пояс, перевести текст на понятный пользователю язык... Также думаю оно должно хранить интерфейсы и сигнатуры всего, за что оно отвечает - IDataContext, IBaseEntity, IGenericRepository<T>, IAuthorizationServices.... "Master" тоже в принципе на обслуживании всех аппсов, так как справочник стран никому в чистом виде нафиг не нужен. Поначалу и вырисовался этот отдельный мастер со своими моделями и сервисами (как логик, так данных). Отдельно от самого суита/коре потому что в случае десктопной версии аппса - коре в виде длл идет к пользователю на комп смело и дружно вместе с аппсом. А мастер со своим UserServices и прочем прячется за WebAPI. Но вроде решили что мастер - это часть этого некоего коре потому модели и дата и ушли туда. Хотя сейчас кажется, что или я не до понял и придумали не верно...
skyANAА в чём собственно сомнения?Что стоимость содержания этого зоопарка будет меньшей, чем стоимость всех костылей для унифицированной, одной на все слои от DB до UI, POCO модели.

>> Что-то как-то толсто.
То есть?

>> Можно глянуть?
Нет, она в глуьоком симбиозе с костылями, уже не отличить где модель, а где костыль :) Причем что из всего перечисленного она пребывает только в скл, монго и джейсоне.

A должен ли конкретный DAL знать кроме ентитей и таблиц в бд еще про какие-то доменные модели и как в них маппить то что он получает из базы? или же это задача того, кто над DAL эти модели пользует?