Архитектура/структура веб-сервиса ASP.NET
Я собираюсь создать новый веб-сервис asp.net (платформа.NET 2.0), функциональность веб-сервиса состоит в том, чтобы получить вход xml, работать, соответствующая операция (добавляют/изменяют/удаляют) на основе входа и кодов возврата, который указывает на состояние операции. Я планирую реализовать две архитектуры слоя (Бизнес-слой и слой базы данных) для этого веб-сервиса, мог любой советовать, является ли это правильной структурой, или любая другая структура работала бы хорошо, чем это. В основном мне нужны некоторые исходные данные при разработке веб-сервиса.
Заранее спасибо.
Спасибо, Muru
3 ответа
Я бы написал веб-службу с использованием ASMX, потому что с ним легче разобраться, с чего начать.
Реализуйте DAL с помощью ADO или LINQ (может быть более простой вариант, поскольку он выполняет все сопоставления за вас, и хорошо бы узнать что-то новое, imo).
Как вы собираетесь вызывать веб-службу? Вы обдумывали, как вернуть код статуса? Вы можете изучить JavaScript и Ajax, чтобы вернуть настраиваемые объекты клиенту, или вы можете изучить протокол SOAP, основанный на xml.
Также могу порекомендовать хорошее чтение - ASP.Net и Ajax: создание архитектуры веб-приложений. Может дать вам лучшее представление о том, какие у вас есть варианты.
Я всегда использую одну и ту же модель: уровень услуг / бизнеса и уровень базы данных. Когда дело доходит до Visual Studio, у меня есть 4 или 5 проектов:
1 с веб-сервисом с именем project.webservice (ТОЛЬКО задача - получать входные данные и передавать их на уровень, который думает (бизнес-уровень), поэтому тестирование легко выполняется для бизнес-уровня
1 с помощью уровня сервиса с именем project.service, который выполняет фактическую работу (решает, какой должна быть операция, вызывает правильные методы базы данных и т. д.)
1 с помощью логики базы данных, называемой project.datalayer, который может быть кодом ADO.Net или платформой Entity.
1 с классами данных, называемыми project.model. Эти классы возвращаются кодом ADO.Net и используются службой и проектом веб-службы. Я использую структуру сущностей. Я обычно пропускаю этот проект, потому что сам EF дает мне классы данных, которые создает EF. Иногда клиенты не хотят использовать классы данных EF, тогда я создаю проект project.model и позволяю слою данных переводить классы данных EF. к классам данных project.model
1 с помощью testproj ect с именем project.test
хм, это помогает,
Мишель
Модель предметной области должна выражать бизнес-логику способом, независимым от граничных технологий , таких как веб-службы WCF или ASP.NET.
Это добавляет требование третьего уровня:
- Служба
- Модель домена
- Доступ к данным
Если вы не создаете отдельный уровень для интерфейсов конкретной технологии (Служба), вы можете как ну просто создайте одно монолитное приложение, потому что вы все равно не сможете повторно использовать бизнес-логику.
Раз уж мы это делаем: используйте WCF, а не ASMX, для веб-сервисов.