Я думаю, що дискусія щодо використання програмно-сервісного використання та взаємодії з людьми є чіткою.
Але якщо я маю створити додаток, який використовує як програмний API, так і веб-сайт, який використовує дані, підключені тим самим API, чи прихиляється це до використання лише ASP.NET?
Наскільки легко інтегрувати ASP.NET і WCF для роботи над одним додатком?
Відповіді:
Що стосується написання однієї програми, яка використовує як ASP.NET/MVC, так і WCF, це не чудово. WebAPI, можливо, покращив питання, але в одному з проектів, який я знайомий з тим, що використовували WCF і MVC в одному додатку, вони в кінцевому підсумку підтримували два різних набори моделей для представлення одних і тих же концепцій - одну для коду WCF і одну для MVC код. Ви можете уявити всіх картографів, які вони мали написати, щоб перекласти речі між двома моделями - там було багато рядків коду, яких можна було / слід було б уникати.
Частина, чому це сталося, полягає в тому, що об’єкти запиту та відповіді WCF повинні бути анотовано за допомогою [DataContract] та їх властивостей за допомогою [DataMember], тоді як MVC цього не вимагає. З іншого боку, ідіоматичний MVC бажає ViewModels, які мають інші цілі, ніж WCF DataContracts. Звичайно, можливо, що використання двох повних наборів об’єктів домену мало більше спільного із законом Конвея, ніж конфлікт WCF & MVC, але варто зазначити, що WCF та MVC мають різні цілі та вимоги щодо виходу та вводу.
Особисто я частково розробляю простий, але потужний сервіс, орієнтований на задній інтерфейс API, особливо коли ви хочете отримати декілька клієнтів. Я думаю, поява відмінних фреймворків JavaScript MVVM та micro-MVC робить це природним вибором, оскільки написання коду програми за допомогою BackboneJS , KnockoutJS та інших дозволяє створити сприятливе середовище розробки. Потім ви можете споживати задній кінець у мікропередачі MVC на свій вибір для створення веб-програми або на мобільному клієнті, і ваші партнери можуть споживати той самий API також віддалено.
Пропозиція
Або WebAPI, або стек послуг можуть бути хорошими кандидатами для створення API заднього кінця. Я рекомендую Service Stack, оскільки я використовував його останні кілька місяців і вважав, що він є відмінною заміною WCF. В даний час я пишу навчальний серіал з сервісного стека в своєму блозі .
Службовий стек підтримки груп розмістив приклад програми, що використовує структуру для розробки клону StackOverflow, який показує модель розвитку, яка, на мою думку, є особливо переконливою. Він передбачає простий, заснований на моделях сервіс, задній кінець, який ви можете уявити, що його споживають веб-сайт MVC, мобільний додаток або майже будь-що інше легко. Цілі дизайну ServiceStack чітко заохочують схему, яка повинна призводити до меншої зв'язку між клієнтом і сервером. Ідея полягає у тому, щоб уникнути балакучих API з дзвінками, як GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)на користь меншої кількості методів. Ви можете реалізувати те саме у службовому стеку, як цей:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
Вигода, на мій погляд, є те , що замість того , щоб ваш бізнес - логіки поширення над великим і великою кількістю окремих методів GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), все це в одному місці. Це повинно призвести до отримання більш корисного коду.
За збігом обставин, Stack Exchange найняв оригінального автора Service Stack . Він продовжує активно займатися проектом Service Stack.
Мені особливо подобаються черги на повідомлення щодо певних речей - і хоча WCF дозволений для цього, WebAPI цього не робить. ServiceStack дозволяє використовувати ту саму веб-службу через MQ. Для отримання додаткової інформації про це дивіться хост Redis MQ за адресою: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb відповів правильно IMO, але я хотів продовжити цю відповідь. Веб-API ASP.NET, який наразі знаходиться на стадії бета-версії, і проект OSS - це найближча рамка, яку ви шукаєте.
Короткий опис продукту наступний (цитується зі сторінки ASP.NET Web API ):
ASP.NET Web API - це рамка, яка спрощує створення HTTP-сервісів, що охоплюють широке коло клієнтів, включаючи браузери та мобільні пристрої. ASP.NET Web API - це ідеальна платформа для побудови RESTful додатків у .NET Framework.
Що стосується клієнтської програми, яку ви можете використовувати для споживання свого веб-API, то це, звичайно, не повинно бути додатком ASP.NET. Ви можете споживати свій API зі статичною HTML-сторінкою за допомогою JavaScript. Ви можете це легко зробити за допомогою деяких корисних бібліотек JavaScript, таких як jQuery.
З іншого боку, ви, звичайно, можете споживати свій API на сервері сайту в будь-якій програмі ASP.NET. Проект Web API також представив новий клієнтський API HTTP .NET під назвою HttpClient, що полегшує споживання HTTP-послуг.
Загалом, тут вам знадобиться хороший набір ресурсів:
Початок роботи з веб-API ASP.NET - Підручники, відео, зразки
Пам'ятайте, що проект все ще знаходиться на стадії бета-версії. Я рекомендую вам слідкувати за блогом Хенріка Ф Нільсена, де він розміщує інформацію про останні неопубліковані оновлення проекту. Ви можете знайти вихідний код проекту та потік розробки проекту ASP.NET Web Stack .
Я думаю, що нинішня думка полягає у використанні веб-API MVC замість WCF для REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
Модель розробки досить близька, і ви обійти іноді неприємну конфігурацію WCF.