Ответ 1
Возврат IHttpActionResult
обеспечивает хорошее разделение проблем.
Контроллер может сконцентрироваться на ответе на запрос наиболее разумным образом (коды состояния, сообщения об ошибках и т.д.). Другой (сервисный) уровень может фокусироваться на фактическом извлечении и преобразовании бизнес-данных.
Побочным эффектом является то, что ваши методы управления становятся более подверженными тестированию. Рассмотрим следующий простой пример:
public class MyController : ApiController
{
//or better yet, dependency-inject this
SomeService _service = new SomeService();
public IHttpActionResult Get(int id)
{
if (id < 0)
return BadRequest("Some error message");
var data = _service.GetData(id);
if (data == null)
return NotFound();
return Ok(data);
}
}
Не только этот метод логически понятен, просто прочитав его, но теперь вы можете легко и естественно протестировать логику, что-то вроде (используя синтаксис NUnit):
[TestFixture]
public class MyControllerTests
{
[Test]
public void Get_WithIdLessThan0_ReturnsBadRequest()
{
var controller = new MyController();
int id = -1;
IHttpActionResult actionResult = controller.Get(id);
Assert.IsInstanceOf<BadRequestErrorMessageResult>(actionResult);
}
}
Аналогично, вы можете высмеять уровень сервиса и проверить, что происходит, когда вы передаете известные параметры id
контроллеру и т.д.
Вот хорошая статья о Модули тестирования устройств в Web Api