Создание / предоставление служб WCF из существующего приложения ASP.NET

Question

Нам необходимо предоставить некоторые службы (например, AddressValidatorService, CustomerFinderService), которые в настоящее время находятся в приложении ASP.NET, другим приложениям в нашей организации. Представление этих сервисов через WCF кажется естественным соответствием, но я не вижу каких-либо рекомендаций о том, как поместить эти общие сервисы в оболочку WCF таким образом, чтобы мое существующее приложение ASP.NET могло продолжать использовать их с минимальными затратами. изменения кода и / или осознание того, что служба, которую они используют, больше не находится в процессе.

Я особенно ищу рекомендации о том, как структурировать существующее решение ASP.NET и разместить ли наш новый WCF в том же решении или в каком-то новом совместном решении WCF, на которое ссылаются как наше приложение ASP.NET, так и внешние вызывающие абоненты.

Кроме того, является ли плохой практикой просто продвигать DTO, которые в настоящее время потребляются только в процессе через ASP.NET, в полноценные контракты на передачу данных или предпочтительнее создавать дубликаты DTO, которые явно декорированы [DataContract]? Последнее похоже на кошмар обслуживания.

Answer 1

Чтобы ответить на ваш второй вопрос:

Кроме того, является ли плохой практикой просто продвигать DTO, которые в настоящее время потребляются только в процессе через ASP.NET, в полноценные контракты на передачу данных или предпочтительнее создавать дубликаты DTO, которые явно декорированы [DataContract]? Последнее похоже на кошмар обслуживания.

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

Последняя может иметь тенденцию становиться трудной для любой развивающейся системы, но тогда у вас есть различные инструменты с открытым исходным кодом (такие как AutoMapper), которые облегчают ваши картографические ночные кошмары.

Answer 2

Если они представлены как статические службы страниц, волшебной обертки нет - вам нужно переместить код в класс реализации автономного сервиса и поместить файл .svc перед ним.(Или используйте активацию без файлов WCF4, или фабрику обслуживания, но это немного отходит от основного вопроса здесь.)

Если они представлены как ASMX, вы можете фактически поместить фасад ASMX перед WCFкласс обслуживания и получите базовые ответы HTTP / XML / ASMX, как если бы вы работали с устаревшими веб-сервисами ASMX.Вы предоставляете тот же класс обслуживания WCF через стандартную конфигурацию WCF для не-унаследованных потребителей.

Наконец, вы можете представить любую службу WCF как basicHTTP с помощью serviceMetadata + httpGetEnabled, и вы получите конечную точку службы, которую можно использовать по наследствупотребители услуги ASMX.

http://msdn.microsoft.com/en-us/library/ms751433.aspx

Answer 3

Вы можете преобразовать существующий проект в WCF, а затем продолжать использовать его в процессе, используя ссылку на проект.Затем он может быть использован вечным источником с помощью клиента WCF.Клиент WCF преобразует имя класса из ClassName в ClassNameClient при использовании через WCF, но класс будет работать почти так же.

Например:

MyClass obj = new MyClass();
obj.DoSomething(withData);

Стал бы:

MyClassClient obj = new MyClassClient();
obj.DoSomething(withData);

Вы бы опубликовали проект WCF в какой-либо конечной точке, например, address.example.com, а затем использовали бы ссылку на сервисную конечную точку для ссылки на код, например, ссылку на проект, в других ваших проектах.*

Обратите внимание, что, хотя изменение, на которое ссылаются внешние проекты, не повлияет на изменение, или не будет знать, что данные передаются по сети, если у вас есть разговоры по данному проекту, это определенно приведет к снижению производительности.Возможно, вы захотите объединить связанные методы в отдельные методы, чтобы сэкономить при циклическом отключении.