У меня есть приложение на работе, которое имеет веб-интерфейс и интерфейс службы WCF.Другое приложение (WinForms) использует службу WCF для предоставления тех же функций, что и веб-приложение, только в контексте того, что делает приложение WinForms.Приятно то, что реальная функциональность находится на бизнес-уровне, а веб-приложение и служба WCF просто представляют другой пользовательский интерфейс и метод доступа.
Из того, что вы описываете, что-топохоже будет работать.Реальный ключ заключается в том, чтобы убедиться, что как можно меньше бизнес-логики встроено в ASPX-страницы.Все, что вам нужно, вам придется заново создать для стороны WCF.
Итак, вы хотите создать набор классов бизнес-логики, которые могут выполнять реальные функции приложения.Ваши веб-страницы содержат логику представления.Если вы настроите его таким образом, довольно просто создать службу WCF, которая предоставляет ту же бизнес-логику для вызова программ.Эта часть - настоящий ключ ко всему.Вы хотите, чтобы логика находилась в одном месте, поэтому ее изменение изменит ее одновременно для обоих типов абонентов.
Если вы используете одну из привязок WCF веб-службы, вы сможете вставить файл службы в веб-приложение и разместить их вместе.Если вы используете такие вещи, как аутентификация в активном каталоге, вы сможете использовать ее одновременно для обоих типов доступа (поскольку это внутренняя служба WCF, а не общедоступная служба Интернета, которая будет работать нормально).
Сначала я начну со стороны веб-приложения, а когда оно выполнит то, что вам нужно, вы можете добавить службу WCF, чтобы сохранить проект в управляемом масштабе.
Что касаетсяWCF против удаленного взаимодействия, в этом случае я бы предпочел WCF.Он ДЕЙСТВИТЕЛЬНО хорошо сочетается с веб-приложениями.
edit:
1) Интерфейс - вам потребуется класс в файле .svc для реализации вызовов служб, несмотря ни на что.Интерфейс требуется в качестве контракта на обслуживание для некоторых типов сервисов (basicHTTPBinding, который основан на SOAP), но не для других (webHTTPBinding, который основан на REST).В любом случае, я бы, вероятно, написал бы интерфейс: он позволяет изменять реализацию службы без изменения контракта на обслуживание, что необходимо для согласованности с клиентами.
2) Услугу можно вызвать извеб-приложение, но оно добавит дополнительный уровень работы в веб-приложение.Для сервисов HTTP это также означает, что ваш сервис XML будет сериализовать все, тогда ваше веб-приложение должно будет немедленно десериализовать его.Сериализация XML несет существенный удар по производительности.Я бы избегал этого метода, поскольку веб-приложение может связывать данные с бизнес-объектами, возвращаемыми бизнес-уровнем, ОЧЕНЬ более эффективно (и WCF автоматически сериализует его для клиентов службы XML).Было бы одно дело, если бы вашему веб-приложению нужно было вызывать другую службу в другом приложении, но в этом случае это не тот путь.
3) Если он общедоступный, то его аутентификация меняется.Для внутренних вещей вы можете позволить IIS обрабатывать аутентификацию с использованием Active Directory.Если у вас есть интернет-клиенты, их, вероятно, нет в Active Directory, и вам нужно будет использовать другой метод.(HTTP Basic и Digest auth должны быть в порядке, или вы можете сделать что-то вроде добавления имени пользователя / пароля в качестве параметров к методам, которые требуют аутентификации. Обязательно используйте SSL в службе!)