使用 RestSharp、POST 请求进行批量分配 - MVC3
我一直在做大量研究,试图找到与我的 ASP.NET MVC3 应用程序通信批量分配 POST 请求的最佳方法,但没有取得太大成功。
场景如下:
就像我提到的,我有一个带有标准 REST 方法的 ASP.NET MVC3,我试图用它与桌面应用程序(另一个内部编写的应用程序)进行通信。首先作为原型,我们只是通过 WebClient,然后让 MVC3 应用程序解析 XML 文档。 为了维持这种行为,我们必须不断构建多种方法,一种用于 XML 文档解析,另一种用于网站上的标准模型使用。如果可以的话,我想远离它。
经过所有研究后,我遇到了 RestSharp,我想知道是否有某种方法可以使用 RestSharp 处理批量分配 POST 请求。我希望能够执行以下操作:
在 MVC3 应用程序中...
public class RegistrationRequest {
public string Email { get; set; }
public string RequestedUserName { get; set; }
public bool Register(string domain) {
// Do registration stuff.
}
}
public class AccountController : Controller {
[Authorize,HttpPost]
public ActionResult Register(IEnumerable<RegistrationModel> models) {
return models.Any(model => !model.Register(this.Url.DnsSafeHost))
? new HttpStatusCodeResult(400)
: new HttpStatusCodeResult(200);
}
}
在桌面应用程序中...
public class RegistrationRequest {
public string Email { get; set; }
public string RequestedUserName { get; set; }
}
public class RegistrationService {
public void CreateUsers() {
List<RegistrationRequest> registrations = new List<RegistrationRequest>();
// list of requested users built up by app
var client = new RestClient(baseUrl);
var request = new RestRequest("Account/Register", Method.POST);
//request.AddAllMyObjects(registrations);
var response = client.Execute(request);
}
}
任何人都可以给我任何有关如何实现此目标的指示吗?
I've been doing a lot of research trying to find the best way to communicate a mass assignment POST request with my ASP.NET MVC3 app without much success.
Here's the scenario:
Like I mentioned, I have a ASP.NET MVC3 with standard REST methods, with which I'm trying to communicate with a desktop application (another app written in-house). To start with as a prototype, we just used the brute force XML document upload through WebClient and then having the MVC3 application parse through the XML document.
In order to maintain this behavior we would have to be constantly building multiple methods, one for the XML document parsing, and one for standard model usage on the website. I'd like to stay away from that if I can.
After all my research I came across RestSharp and I'm wondering if there is someway to handle mass assignment POST requests using RestSharp. I'd like to be able to do something like the following:
In the MVC3 app...
public class RegistrationRequest {
public string Email { get; set; }
public string RequestedUserName { get; set; }
public bool Register(string domain) {
// Do registration stuff.
}
}
public class AccountController : Controller {
[Authorize,HttpPost]
public ActionResult Register(IEnumerable<RegistrationModel> models) {
return models.Any(model => !model.Register(this.Url.DnsSafeHost))
? new HttpStatusCodeResult(400)
: new HttpStatusCodeResult(200);
}
}
In the desktop app...
public class RegistrationRequest {
public string Email { get; set; }
public string RequestedUserName { get; set; }
}
public class RegistrationService {
public void CreateUsers() {
List<RegistrationRequest> registrations = new List<RegistrationRequest>();
// list of requested users built up by app
var client = new RestClient(baseUrl);
var request = new RestRequest("Account/Register", Method.POST);
//request.AddAllMyObjects(registrations);
var response = client.Execute(request);
}
}
Can anyone give me any pointers on how to achieve this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在浏览了文档并与 John Sheenan 快速来回查看后,我发现这目前是不可能的。我最终向我们开发的 API 提出了单一的请求。由于它在后台运行,因此它并不会真正影响桌面应用程序的用户体验,而且无论如何,请求都必须更小、更简洁。
我发现这实际上使我们能够在每个单独的通过/失败案例中获得更好的结果并适当地处理这些情况。虽然这可能很好,但这个“一次一个”的请求最终被证明更好。
After looking through the docs and a quick back and forth with John Sheenan, I found that this is not currently possible. I ended up making singular requests to the API we developed. Since this runs in the background, it doesn't really affect the user experience on the desktop app and the requests were must smaller and more succinct anyways.
I found that this actually enabled us to get better results anyways on each individual pass/fail case and handle those appropriately. While it might have been nice, this "one at a time" request actually proved to be better in the end.