веб-сервисы с шаблоном репозитория в С # и WCF?

Думаю, я понимаю вашу дилемму. Если я правильно понимаю, ваш слой услуг состоит из чистых вымыслов. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design).

Если я правильно предполагаю выше, то внедрение WCF никак не повлияет на ваш уровень сервисов. WCF - это, по сути, дополнительный уровень представления, который обеспечивает взаимодействие, находясь между уровнем представления пользовательского интерфейса и любыми уровнями бизнес-логики. Таким образом, ваши службы WCF затем будут вызывать ваш уровень служб, который может обращаться к репозиториям по мере необходимости.

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

Удачи, и дайте мне знать, могу ли я чем-то помочь.

Во-первых, не все вызывающие должны использовать один и тот же API репозитория; особенно это касается внешней компании.

WCF основан на интерфейсе. Это означает, что если необходимо повторно использовать некоторый логический код, можно использовать IoC / DI для внедрения WCF, а не DAL (но с использованием того же интерфейса) - с помощью совместного использования сборки. Похоже, это то, что вы делаете. Это работает во многих случаях, но не во всех; По сути, API-интерфейсы на основе веб-сервисов часто необходимо разрабатывать по-другому, чтобы быть оптимальными. Он также не на 100% чист с точки зрения SOA, но он выполняет свою работу и позволяет использовать более интеллектуальные объекты домена, поэтому в сценарии интрасети (и т. Д.) Это (IMO) совершенно разумно.

Внешний вызывающий объект обычно просто использует API-интерфейсы на основе wsdl / mex (а не совместное использование сборки), но все возможно ...

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

Мои приложения делают аналогичные вещи, но всем им нужен доступ к уровню обслуживания - ну, бизнес-логике и получению информации ...

В этом случае - всегда предпочтительнее использовать совместное использование сборки с уровнем сервиса, а не предоставлять веб-службу WCF с использованием протокола HTTP или TCP на wcf - например?

Еще раз спасибо

Вопрос о том, следует ли делиться своими сборками Service / API с клиентскими приложениями, довольно субъективен. Если вы являетесь полноценным магазином Microsoft и используете .NET для всего своего стека приложений, то я бы сказал, что совместное использование API - отличный способ получить повторное использование кода (вы должны быть осторожны при разработке своего API, чтобы не истекать кровью. проблемы домена, такие как репозитории, в вашу презентацию.) Если у вас нет никаких планов по переносу ваших клиентских приложений на другие платформы (то есть вы планируете оставаться на .NET в обозримом будущем), то я думаю, что это вполне приемлемо, чтобы поделиться ваши сборки Service / API (и даже в этом случае в многоплатформенной клиентской среде совместное использование Service / API с .NET-клиентами должно быть приемлемым). Всегда существует компромисс между «архитектурно идеальным» и «практичным и достижимым» в пределах бюджета'. Вы можете потратить МНОГО времени, денег и усилий, пытаясь достичь архитектурного идеала, когда разрыв между этим и практическим часто не так уж велик. Выбор НЕ совместно использовать API и, по сути, воссоздать его для поддержки «правильной» SOA, использующей только контракт, может фактически увеличить объем работы и вызвать проблемы с обслуживанием, которые, вполне возможно, не стоят того для вашего конкретного проекта в данный конкретный момент. Учитывая, что вы уже в целом «ориентированы на услуги», если в будущем вам понадобится выгода, которую может предложить клиентское потребление только по контракту, тогда вы уже готовы к этому. Но не заходите слишком рано.

Учитывая ваши потребности, исходя из того, что я смог почерпнуть из этих сообщений, я думаю, что вы тоже на правильном пути, начиная с ваших услуг. Репозиторий (a la Evans, DDD) определенно является предметной областью, и поэтому вам действительно не следует беспокоиться об этом с точки зрения вашего уровня представления. Ваши услуги - это шлюз к вашему домену, который является домом для вашей бизнес-логики. Репозитории - это просто средство поддержки, которое помогает вам добиться изоляции домена от хранилища данных (на самом деле это прославленные коллекции, и, честно говоря ... они могут быть немного неудобными в динамическом и сложном домене. Простые сопоставители данных, (Fowler, PofEAA) часто намного проще в обращении и менее сложны в долгосрочной перспективе, и позволяют централизовать более адаптируемое поведение вокруг вашей логики извлечения данных в ваших доменных службах.) Помимо интенсивного использования вызовов AJAX к службам REST. , если вы предоставляете соответствующие службы / API для своего домена, это единственное, о чем вашим клиентам следует беспокоиться. Оберните всю остальную бизнес-логику полностью в рамках вашего домена и сделайте своих клиентов максимально легкими и абстрагированными от таких понятий, как «Репозиторий» или «Картограф данных» и так далее.

По моему опыту, единственная концепция, не относящаяся к сервису или API, которая должна быть разделена через границу между клиентом и доменом, - это контекст ... и пересечение этой границы в сервисно-ориентированном приложении может быть заведомо трудным.