Веб-сервис или DLL?

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

Вы правы, веб-сервисы являются большим количеством стычки на основе опыта и намного медленнее. Я предлагаю - делают PONO (простой объект .NET), но используют интерфейсы. Изучите платформу Spring.NET - она может экспортировать этот объект для Вас как безотносительно типа (веб-) сервиса, таким образом, Вы не должны делать plumming. На стороне клиента можно также использовать пружину, чтобы сделать внедрение зависимости и решить, хотите ли Вы незавершенный DLL или реализацию веб-сервиса, только путем изменения значения в файле конфигурации. Также Spring имеет Кварцевую интеграцию планировщика, Вы могли бы хотеть изучить его также.

Используя DLL правильный путь, это быстрее, и он обеспечивает свободу в будущем для создания веб-сервиса с использованием этих dlls (при необходимости) с большей безопасностью по веб-сервису.

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

Нам действительно нужно больше информации. Его трудное для ответа знанием, кто точно Вы требования. Многоуровневый подход (dll/separate класс) прост и быстр. Многоуровневый подход (веб-сервис) позволит Вам иметь одну среду и дает Вам больше абстракции. Можно изменить код позади веб-сервиса с изменением клиентов.

Но для оценки этого, мы должны были бы знать то, что проект - то, что сделает этот dll. Иначе Вы просто слышите предпочтения народов.

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

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

я разрабатываю подобное приложение. подход, который я проявил, должен иметь мою логику извлечения в dll's. это выставляется через веб-сервис. я нахожу веб-сервисы более простыми, поскольку я не нуждаюсь к интерфейсам deleop или выставляю свои объекты (я использую классы для инкапсуляции данных) на клиенте. у меня затем есть веб-разработчики, и разработчики winforms пишут свой собственный уровень представления. в то время как существуют за и против (привычка входят в них), веб-сервисы более просты, поскольку у меня есть единственный слой. с помощью дистанционной работы мне нужна дополнительная библиотека интерфейсной или стороны клиента, которая должна быть установлена на каждом клиенте. этим путем я управляю просто стороной сервера, в то время как различные графический интерфейсы пользователя независимы. я точно так же, как loosy связанное кодирование. мы выполняем многочисленные сервисы окон, которые также используют веб-сервисы. наш - кредитная карта org, и мы взаимодействуем с многочисленными системами. веб-сервисы дают использованию наибольшую гибкость.

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