2010-01-05 3 views
1

Я разрабатываю веб-приложение. Это скорее приложение для бизнес-приложений, чем веб-сайт. Я использую ASP.NET MVC, SQL Server 2008, и я приобрел LLBLGen. Мне нужно предоставить какой-то API для третьих сторон. Например, если это медицинское приложение, третьи стороны, возможно, нуждаются в CRUD-пациентах, извлекают сложные отчеты, задействуют определенные виды рабочих процессов и т. Д.ASP.NET MVC и предоставление стороннего API

Каков наилучший способ сделать это с помощью MVC, не обращаясь к архитектуре астронавта маршрут. Нужен ли мне целый слой типа «веб-службы» или я могу повторно использовать мои контроллеры в MVC? Имеет ли смысл использовать этот вид API через MVC? Оптимально, мне нужно решение, которое включает в себя наименьшее количество повторений кода. Я нашел кое-что, что делал REST с MVC, но некоторые из них довольно неоднозначны, и я не уверен, имеет ли это смысл. Мне нужен разумный API, но я не обязан следовать всем принципам религии REST или что-то в этом роде. Мне просто нужен какой-то API в дополнение к предоставлению HTML-интерфейса для сайта, будь то REST, SOAP, что угодно.

Кроме того, какие варианты имеют отношение к URL-адресам? Не все в приложении сопоставляется с чем-то вроде сайта/продуктов/идентификатора продукта. Некоторые из них связаны с привлечением сложных рабочих процессов и т. Д.

ответ

0

Если у вас будет веб-сайт и веб-сервис, я бы рассмотрел возможность разделения доступа к данным и сущностей из MVC.

Таким образом, ваш веб-сервис может выполнять те же действия, что и ваш веб-сайт. У меня был бы сервисный уровень, с которым они оба взаимодействуют. После этого вызовы затем переходят в базу данных и возвращают объекты, и ни веб-служба, ни веб-сайт не могут взаимодействовать с этим слоем.

Эта концепция также известна как Separation of Concerns.

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