Многие профессиональные приложения на C # являются n-уровневыми. В вашем случае вы, вероятно, наложили бы это следующим образом:
На сервере:
-Базовый магазин
Уровень доступа к базе данных / бизнес (иногда два отдельных компонента, в зависимости от сложности приложения)
-Веб-сервис
На клиенте:
-Web Сервисный клиент
-Любые другие слои для поддержки функциональности клиента.
Таким образом, база данных будет выглядеть как таблицы в Oracle или Microsoft SQL Server и будет располагаться на вашем сервере.
Уровень доступа к базе данных / бизнес-уровень будет вашим кодом, который получает и сохраняет данные в / из вашей базы данных. Он также может содержать бизнес-объекты, которые в основном являются классами, которые имеют свойства, представляющие ваши данные из вашей базы данных. Преимущество уровня доступа к данным заключается в том, что иногда для чтения и записи в базу данных может потребоваться специализированный код, и вы не хотите, чтобы этот код распространялся через ваше приложение. Таким образом, вместо этого вы можете вызывать функции на уровне доступа к данным, которые загружают необходимые данные в объекты, поэтому остальная часть вашего приложения просто взаимодействует с обычным старым объектом / классом .NET. Они называются POCO, что означает нечто вроде Plan Old CLR Object. Разумеется, существует множество вариантов, поскольку люди используют разные подходы к проблеме выделения доступа к базе данных. Также он служит для минимизации критических изменений при изменении базы данных. Поскольку логика доступа к базе данных не разбросана по всему приложению, существует меньше мест, которые необходимо обновлять при изменении базы данных (например, добавление новых столбцов в таблицу или изменение имени).
Иногда бизнес-уровень будет его собственным уровнем и будет содержать большую часть «логики» приложения. Он будет находиться между слоями доступа к данным и веб-сервисов. Используя концепции из сервис-ориентированной архитектуры (SOA), вы можете иметь службу аутентификации и службу обработки веб-запросов. Эти сервисы очень похожи на класс, который всегда создается, ожидая обработки запросов. Ваша служба обработки веб-запросов примет запрос и, возможно, сначала вызовет службу аутентификации для проверки учетных данных, прежде чем выполнить запрос. SOA - одна из тех вещей, которые, я думаю, следует использовать только в случае необходимости. В некоторых случаях использование объектно-ориентированных техник даст вам те же преимущества. Хотя не всегда. SOA, если все сделано правильно, является более масштабируемым, поэтому действительно зависит от того, предлагает ли SOA дополнительные преимущества, которые вам нужны.
Веб-служба будет нести ответственность за получение запросов из Интернета, их анализ / интерпретацию и выполнение этих запросов путем обращения к бизнес-уровню для обновления или получения данных.
Таким образом, концепция заключается в том, что многие пользователи вашего сервиса могут публиковать обновления своих песен через ваш сервис.
У вашего клиента будет слой «клиент веб-службы», который будет отвечать за форматирование запросов в сообщениях, их отправку в веб-службу и получение сообщений из веб-службы. Вы бы поместили очень мало «логики» приложения в слой веб-сервисов.
Теперь все это, вероятно, излишне и неэффективно для того, что вы хотите сделать, поскольку вы просто хотите что-то для себя, но это основная анатомия многих приложений веб-сервиса и было бы хорошим упражнением в обучении. Все назначение слоев - разделение и простота. Хотя большее количество слоев / компонентов делает приложение в целом более сложным, это означает, что каждый компонент проще. Это означает, что легче обернуть голову проблемами, когда вы имеете дело только с одним компонентом, который взаимодействует только с парой других компонентов (окружающий слой). Таким образом, существует тщательный баланс между несколькими компонентами и многими компонентами. Слишком мало, и они становятся монолитными и сложными в управлении. Слишком много, и они переплетаются сложными способами. Я слышал, что это говорит что-то вроде «Если класс становится слишком большим и слишком сложным, то разделите его на несколько классов». В сущности, не начинайте делить вещи на хрен, потому что это звучит как то, что нужно делать. Оцените, насколько сложным будет ваш компонент, прежде чем решить, хотите ли вы разделить его. Иногда для простых случаев у вас есть слой, служащий более чем одной цели, чтобы сделать это быстрее и упростить общий дизайн. Суть в том, чтобы применять эти концепции там, где это необходимо. Вы узнаете, что уместно с опытом, и вы, очевидно, понимаете, что вы можете узнать больше всего, "делая".
"Может ли VBScript вызывать COM-компонент?" Вы можете скомпилировать .NET DLL с поддержкой COM. Многие старые вещи могут вызывать COM-библиотеки.
Я погуглил: vbscript dll
и получил это: VB Script и DLLs
"Это безопасно сделать?" Ваш веб-сервис будет там, где вас больше всего беспокоит безопасность. Это безопасно, только если вы разрабатываете с точки зрения безопасности и не облажались. Хотя иногда мы все облажались, а это значит, что нет никакой гарантии, что он будет абсолютно безопасным.