Веб-сервисы с шаблоном репозитория в C# и WCF?
Может кто-нибудь подтвердить лучший способ интегрировать шаблон хранилища с веб-сервисами.... Ну, на самом деле у меня есть мой шаблон хранилища, работающий сейчас в C#. У меня есть 3 проекта, DataAccess, Services и мой уровень представления.
Проблема в том, что мой уровень представления состоит из нескольких вещей... У меня есть сайт ASP.NET MVC, у меня есть приложение WPF, и мы собираемся создать еще один сайт + внешней компании также необходим доступ к нашему хранилищу.
В настоящее время я только что добавил слой служб в качестве ссылки на каждый из сайтов... Но разве это не обычный способ предоставления доступа к данным через веб-службы? (WCF) - если это так, это нарушит уровень услуг? или я должен преобразовать слой сервисов в веб-сервис?
Кто-нибудь знает, какие плюсы и минусы этого, скорость??
4 ответа
Я думаю, что понимаю вашу дилемму. Если я правильно понимаю, то ваш уровень услуг состоит из чистых выдумок. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design).
Если я правильно придумаю выше, то на уровень ваших услуг вообще не должно повлиять введение WCF. WCF - это, по сути, дополнительный уровень представления, обеспечивающий взаимодействие, находящийся между уровнем представления вашего пользовательского интерфейса и любыми уровнями бизнес-логики. Таким образом, ваши сервисы WCF будут вызывать ваш уровень сервисов, который может обращаться к репозиториям по мере необходимости.
WCF обеспечивает высокую степень взаимодействия, поэтому я считаю, что это отличный выбор. Я бы использовал привязки basicHttp, если вы собираетесь взаимодействовать с разными языками программирования, так как это наиболее гибкий вариант. Не беспокойся о скорости. Существует множество решений для устранения узких мест, возникающих из-за WCF.
Удачи, и дайте мне знать, могу ли я чем-нибудь помочь.
Делить ли ваши сборки Service/API со своими клиентскими приложениями довольно субъективно. Если вы являетесь полным магазином Microsoft и используете.NET для всего своего стека приложений, то я бы сказал, что совместное использование API - отличный способ получить повторное использование кода (вы должны быть осторожны при разработке API, чтобы не допустить потери вопросы, связанные с доменом, такие как репозитории, в вашу презентацию.) Если у вас нет планов переноса ваших клиентских приложений на другие платформы (т.е. вы планируете оставаться на.NET в обозримом будущем), то я думаю, что вполне приемлемо поделиться ваши сборки Service/API (и даже тогда, в многоплатформенной клиентской среде, совместное использование Service/API с клиентами.NET все еще должно быть приемлемым.) Всегда существует компромисс между "архитектурно идеальным" и "практичным и достижимым". в пределах бюджета'. Вы можете потратить ОЧЕНЬ много времени, денег и усилий, пытаясь достичь архитектурного идеала, когда разрыв между этим и практическим часто не так уж и велик. Выбор НЕ использовать API и по существу воссоздавать его для поддержания "правильной" SOA, потребляя только контракт, может фактически увеличить объем работы и создать трудности, связанные с техническим обслуживанием, которые, вполне возможно, не стоят того для вашего конкретного проекта в это конкретное время. Учитывая, что вы, как правило, уже "ориентированы на обслуживание", если в будущем вам понадобится то преимущество, которое потребитель может предложить только по контракту, то вы уже готовы к этому. Но не торопитесь слишком рано.
Учитывая ваши потребности, насколько я могу судить по этим постам, я считаю, что вы на правильном пути и из ваших услуг. Репозиторий (а-ля Эванс, DDD) определенно является проблемой домена, и поэтому вам не нужно беспокоиться об этом с точки зрения уровня презентации. Ваши услуги являются воротами к вашему домену, который является домом вашей бизнес-логики. Репозитории - это всего лишь средство поддержки, которое помогает вам изолировать домен от хранилища данных (это действительно прославленные коллекции, и, честно говоря, они могут быть немного болезненными в динамической и сложной области. Простые средства отображения данных, (Фаулер, PofEAA) часто намного проще в обращении и менее сложен в долгосрочной перспективе, и позволяет более гибко настраивать поведение вашей логики поиска данных в ваших доменных службах.) Помимо интенсивного использования вызовов AJAX для служб REST, если вы предоставляете адекватные сервисы / API для своего домена, это единственное, о чем должны беспокоиться ваши клиенты. Оберните всю остальную часть вашей бизнес-логики полностью в рамках вашего домена и сохраняйте своих клиентов как можно более легкими и абстрагирующимися от таких понятий, как "Репозиторий" или "Data Mapper" и еще много чего.
По моему опыту, единственной не-сервисной или API-концепцией, которой нужно делиться через границу между клиентом и доменом, является Контекст... и, как известно, может быть трудно пересечь эту границу в сервис-ориентированном приложении.
Может быть, веб-сервисы - не лучший способ, если у меня есть полный доступ к сервисной сборке, то я полагаю, что всегда лучше разделить сервисный слой с моими приложениями.
Мои приложения делают схожие вещи, но все они должны иметь доступ к сервисному уровню - хорошо, бизнес-логика и получить информацию...
В этом случае - всегда предпочтительнее использовать совместное использование сборок со слоем службы, а не предоставлять веб-службу WCF с использованием протокола HTTP или с использованием TCP на wcf - например?
еще раз спасибо
Ну, во-первых, не все абоненты должны использовать один и тот же API хранилища; это особенно верно для внешней компании.
WCF основан на интерфейсе. Это означает, что если вам нужно повторно использовать некоторый логический код, можно использовать IoC/DI для внедрения WCF, а не DAL (но с использованием того же интерфейса) - с помощью совместного использования сборок. Похоже, это то, что вы делаете. Это работает во многих случаях, но не во всех; По сути, API, основанные на веб-сервисах, часто должны разрабатываться по-разному, чтобы быть оптимальными. Он также не является на 100% чистым с точки зрения SOA, но он выполняет свою работу и позволяет создавать более интеллектуальные доменные объекты, поэтому в сценарии интрасети (и т. Д.) Это (IMO) вполне разумно.
Внешний абонент обычно использует API на основе wsdl / mex (а не общий доступ к сборке), но все возможно...