I have a method inside MVC Controller which is called from href inside anchor tag.
public ActionResult DoSomething(string value)
{
if(true)
{
return new RedirectResult("http://google.com");
}
}
when I debug and hit that method Response.Redirect does nothing no exceptions either. any ideas?
Thanks in advance!
Use Redirect
return Redirect("http://www.google.com");
Response.Redirect is not preferred way of doing redirects in asp.net mvc
Response.Redirect and ASP.NET MVC – Do Not Mix
Update: It seems that you are trying to redirect ajax request. If you redirect ajax request, your main page won't be redirected.
There are a few things you need to do here to avoid all these issues.
Starting with the AJAX errors you're getting, they most like relate to the javascript debugger, which Microsoft refer to as "BrowserLink".
If you use Firefox or Chrome, this feature simply doesn't work, which is probably the easiest way to avoid the issue, however you can disable the feature here:
You can change the default browser to run the website in just to the left.
In terms of Response.Redirect, I think that's been well covered, you should use return Redirect() instead, however your code needs to be refactored to allow for that.
Assuming that method is a helper method which is required to be separate from the controller itself, there are a couple of main approaches to doing what you're trying to to do.
1) Magic Values
This could include "redirect1" or also commonly null, and would look something like:
public ActionResult MyAction
{
string data = ProcessString("some data");
if (data == null) { return Redirect("google.com"); }
}
public string ProcessString(string input)
{
if (condition) { return null; }
string output = input + "!"; // or whatever you need to do!
return input;
}
2) Handle via exceptions
Assuming the problem is that the data is in some way bad, and you want to redirect away because you cant process it, Exception handling is most likely the way to go. It also allows for different types of exceptions to be raised by a single method and handled independently without having magic values which then can't be used as normal data.
public ActionResult MyAction
{
string data; // remember this will be null, not "" by default
try
{
data = ProcessString("some data");
}
catch (OwlMisalignedException ex)
{
return RedirectToAction("Index", "Error", new { exData = ex.Code });
}
// proceed with controller as normal
}
public string ProcessString(string input)
{
if (condition)
{
throw new OwlMisalignedException(1234);
// this is (obviously) a made up exception with a Code property
// as an example of passing the error code back up to an error
// handling page, for example.
}
string output = input + "!"; // or whatever you need to do!
return input;
}
By using that approach you can effectively add extra return states to methods without having to fiddle with your return type or create loads of magic values.
Don't use throw Exception - either use one of the more specific types ArgumentException and ArgumentNullException will probably come in handy, or create your own types if needs be.
You'll find info on creating your own Exception types on here easily enough.
Related
EDIT:
I just realized that SaveChangesAsync returning 0 doesn't mean that it failed, entity framework will always throw exception when something fails so the check if SaveChanges == 0 is redundant! Save changes should always return 1 in the example below, if something fails then exception will be thrown.
However there are cases when something else is used and it's not entity framework so is this question for.
Servers can fail, when putting all my data access code in controllers I can handle it this way:
[HttpPost]
public async Task<ActionResult<Item>> CreateAsync([FromBody] Item item)
{
await _dbContext.AddAsync(item);
if (await _dbContext.SaveChangesAsync() == 0)
{
return StatusCode(StatusCodes.Status500InternalServerError);
}
return CreatedAtAction(nameof(GetAsync), new { id = item.Id }, item);
}
How should I handle it when my data access is encapsulated in a service layer?
public class ItemsService
{
public async Task<Item> CreateAsync(Item item)
{
await _dbContext.AddAsync(item);
if (await _dbContext.SaveChangesAsync() == 0)
{
return null;
}
return item;
}
}
Then it would be used like that:
[HttpPost]
public async Task<ActionResult<Item>> CreateAsync([FromBody] Item item)
{
// model state validation skipped for the sake of simplicity,
// that would return BadRequest or some more valuable information
var item = await _itemsService.CreateAsync(item);
if (item == null)
{
return StatusCode(StatusCodes.Status500InternalServerError);
}
return CreatedAtAction(nameof(GetAsync), new { id = item.Id }, item);
}
Maybe this works for fine creating because there are only 2 status codes but let's consider updating where there can be more than 2 possible errors like:
Not found (404)
Internal server error(500)
Ok (200)
Code without services:
[HttpPut("{id}")]
public async Task<ActionResult<Item>> UpdateAsync(int id, [FromBody] Item itemToUpdate)
{
var item = await _dbContext.Items.FindAsync(id);
if (item == null)
{
return NotFound();
}
// update item with itemToUpdate
//...
await _dbContext.Update(item);
if (await _dbContext.SaveChangesAsync() == 0)
{
return StatusCode(StatusCodes.Status500InternalServerError);
}
return item;
}
Now with services this can't be properly handled:
public class ItemsService
{
public async Task<Item> UpdateAsync(Item updateItem)
{
var item = await _dbContext.Items.FindAsync(id);
if (item == null)
{
return null;
}
//change some properties and update
//...
_dbContext.Items.Update(item);
if (await _dbContext.SaveChangesAsync() == 0)
{
// what now?
}
return item;
}
}
because it always returns null and there's no way to tell if the item was not found or the saving failed.
How can I handle it properly?
Note: I didn't add DTO or anything like that to keep this example simple.
Your service is responsible for catching all the exceptions it knows how to handle and handles those. All the other exceptions should be reported throught some kind of IServiceResult<T> providing both bool IsSuccessful and AggregatedException Exceptions { get; }. So rather than throw you let the highest level to decide how to react. It's actually the best approach from many points of view, including: purity of your functions (which is a key concept for easy parallezation, isn't it important for server?), clean and maintanable code (consumers of the service should not know/care that much: they just verify whether result is successful and consume the result; otherwise dig into aggreaged exception; might make sense to implement your own type of exception providing methods suitable for needs of your project), ability to procceed on higher-order-functions, which are responsible for actual error handling; take rX as a popular example: .OnError(Action<Exception> handler). There are much more than this, however I don't like to make the answer longer that it needs to be.
As a side note. Make sure you read an introductory lever articles about Maybe and Either monads from Haskell programming language; in case you'd prefer F# more, you can try to seek for Some and Either respectively. There you can find useful methods like .Map(...) and see nice ways to combine/aggregate those in efficient way.
Good luck.
The code with the service is far better. The controller sould delegate business logic to the service layer.
To make your implementation of the service layer more better, you should:
throw custom exceptions when something wrong happened in your service. Example : throw ItemNotFoundExcption instead of returning null. ItemUpdateException when updates failed.
in your controller you need to catch all possible custom exceptions that might happenned and do what need to be done like returning NotFound() for ItemNotFoundException and BadRequest() for ItemUpdateException.
the latter point can be made through custom action filter which helps you make your controller's actions more lean.
It's actually a pretty big topic and there are dozens of options to do it.
I prefer to throw exceptions. You can create your own classes for that or use .net ones. You can have NotFoundException, InternalServerError and etc. Each class can have StatusCode and Message field or whatever you want. Next you need to implement exception filter for asp.net which will handle all exceptions and return response with status code that can be retrieved from exception class.
Another option maybe simpler. You can create a class that will contain StatusCode and object as a result so you will return it from your methods. It's a way to return more then just null or object from your methods.
Few good articles:
Exceptions or error codes
https://www.hanselman.com/blog/GoodExceptionManagementRulesOfThumb.aspx
http://codebetter.com/karlseguin/2006/04/05/understanding-and-using-exceptions/
I have two methods in my controller that are called via ajax on click. Both do the exact same thing (retrieving the same data from a database) and return a partial view along with the model that contains the retrieved data. The only difference is the view.
public PartialViewResult FormA()
{
[...// Code]
return PartialView("_FormA", ModelWithData)
}
public PartialViewResult FormB()
{
[...// same Code as in FormA()]
return PartialView("_FormB", ModelWithData)
}
Both views use the same data but show different things.
If FormB() is called FormA() definitely has been called before.
There must be a way to bypass the second method/database request. It perceptibly slows down the application due to the additional database request.
My question seems really stupid to me, but I'm not able to find a workaround...
Thx for your help!
Yes sure by passing some kind of filter to your action method like below
public PartialViewResult ShowForm(string filter)
{
if(TempData["model"] == null)
{
[...// Code]
TempData["model"] = ModelWithData;
}
if(filter == "some_condition")
return PartialView("_FormA", TempData["model"] as ModelWithData);
else
return PartialView("_FormB", TempData["model"] as ModelWithData);
}
Got your point now. You can use any type of state management mechanish. Say TempData
I'm not really sure what is the prefered way when dealing with record not found in the database. Is it better to write Find method which returns null or Get method which returns RecordNotFoundException?
[AuthenticateFilter(UsernameAndSecretKey)]
[Route("api/v1/activities/emails/{id}")]
[HttpGet]
public IHttpActionResult GetEmailActivity(int id)
{
try
{
// business logic service, could use only db service but this way we can do unit tests (just fill bl service method with fake objects)
var service = new EmailActivityBlService();
// 1. use Find method which returns null in case record with provided id does not exist in db
var model = service.FindActivity(id);
if( model != null )
return Ok(model);
return NotFound();
// 2. or is this approach better
// throws RecordNotFoundException in case row by id is not found in database
return Ok(service.GetActivity(id));
}
catch(RecordNotFoundException e) { return NotFound(); }
catch(Exception e) { return InternalServerError(e); }
}
EmailActivityBlService has next code in case anyone interested (showing only the important part):
private EmailActivityDbService _dbService;
public EmailActivityModel GetActivity(int id)
{
var model = this._dbService.GetActivity(id);
if( model == null )
throw new RecordNotFoundException(); // I suppose System.Data.ObjectNotFound is also suitable
return model;
}
public EmailActivityModel FindActivity(int id)
{
// typical entity framework query
// using(var context = new ..) { return contect.EmailActivity.Where()..SingleOrDefault().ConvertToModel();
return this._dbService.GetActivity(id);
}
UPDATE
Talked with my colleagues, we decided to go with this solution. As why GetActivity returns null instead of throwing Exception, I prefer answer from rboe:
So return null if it is can happen in your domain, that records do not exist (in my experience this is most often the case). If you expect a record to exist and it is not there, then it is valid to throw an exception.
[AuthenticateFilter(UsernameAndSecretKey)]
[Route("api/v1/activities/emails/{id}")]
[HttpGet]
public IHttpActionResult GetEmailActivity(int id)
{
var service = new EmailActivityBlService();
var model = service.GetActivity(id); // returns null in case activity is not found
if( model != null )
return Ok(model);
return NotFound();
}
We avoided any try-catch in the methods and put global filter when Exception occurs:
File: App_Start\WebApiConfig.cs
public class WebApiExceptionFilter : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
actionExecutedContext.Response = actionExecutedContext.Request.CreateErrorResponse(HttpStatusCode.InternalServerError, actionExecutedContext.Exception.Message, actionExecutedContext.Exception);
}
}
Both ways are valid ones.
It is a different emphasis whether you use exceptions or the return value null to indicate non existing records.
Exceptions exist to signal an error state (something happened that is abnormal). The code in the catch-handler is focused on how to deal with an error and not to contain business logic.
If you return null then it will be a normal and 'non exceptional' state in your model.
So return null if it is can happen in your domain, that records do not exist (in my experience this is most often the case). If you expect a record to exist and it is not there, then it is valid to throw an exception.
I disagree with the other answer. In the case of a GetyById method, I wouldn't say to return null instead of throwing because you could argue it was "expected" that there might not be a record with the requested id. This "exceptions for exceptional situations," while often stated, I don't really think is the best way to think about the method's contracts. APIs should make semantic sense, ideally.
Instead, I suggest to throw exceptions whenever the method cannot do what it was told to do. So GetById methods should thrown an exception in the event there is no such record with the requested id in the system. The Find method should probably return an enumerable, which of course could be empty in the event no records match the criteria given.
An API which has a FindById method strikes me as odd; if you are giving the API an ID, that implies the caller could somehow have learned the ID in a previous API call, and so the API shouldn't need to "find" an already known to exist record. It should provide a way to get the record directly by its id. Instead Find should be for locating records when you aren't sure they exist, and using some other criteria.
Given the web service call, I would go with the service calling the GetById method, as the web service caller also learned the id somehow. If the id turns out not to exist, the library can throw the RecordNotFoundException, which causes the service call to return 404.
i have the following Action method that return an _error partial view in case an Exception occur:-
[AcceptVerbs(HttpVerbs.Post)]
public PartialViewResult Register(string id, int classid) {
try
{
Thread.Sleep(3000);
User user = r.FindUser(id);
Users_Classes uc = new Users_Classes();
uc.AddedDate = DateTime.Now;
uc.ClassID = classid;
user.Users_Classes.Add(uc);
r.Save();
ViewBag.classid = classid;
return PartialView("_usersearch2", uc);
}
catch (DataException ex)
{
return PartialView("_error");
}
and the following _error partial view:-
<script type="text/javascript">
alert('The user might have been already Assinged, Search Again to get the latest users');
</script>
The above approach is working fine, but does it consider a bad design to return a partial view to display only an alert ? and is there a better way to do this?
The problem is you are now tying your implementation to your user interface. The Controller suddenly decides how an error message should appear on the client.
What if you want to change it from an alert to displaying a red border around a text input with some description next to it?
Determining how something should be displayed is up to your view. Your controller should only return status codes and then your view should decide what to do.
Instead of returning inline js you should have error handling code on your client side within a js library. Rather than returning the hole js only return the message.
In general, I'd say yes. But, sometimes a bad design is just what the doctor ordered ;)
There's a Controller instance method called Javascript that I use to return executable javascript from my controller, on very limited occasions, when taking the time to do it the "right" way isn't feasible:
[AcceptVerbs(HttpVerbs.Post)]
public PartialViewResult Register(string id, int classid)
{
try
{
... stuff
}
catch (DataException ex)
{
return Javascript("alert('The user might have been already Assinged, Search Again to get the latest users');");
}
}
The fact that something like this exists gives me solace that I'm not completely breaking the law.. unless I'm using it wrong, which I probably am.
I have 2 Action methods in one controller,
Index:
public ActionResult Index(string url)
{
// take the url as a param and do long tasks here
ViewBag.PageTitle = "title";
ViewBag.Images = "images";
// and some more view bags
return View();
}
This index view contains a form which post to another method in the same controller.
public ActionResult PostMessage(string msg, string imgName)
{
// save data in the db
// but on error I want to navigate back to the Index view but without losing data the user fielded before submit the form.
// Also need to pass an error message to this index view to show
}
How to return back to Index view if something went wrong in the PostMessage method, and also don't clear the form fields, plus showing an error message which the PostMessage method specified.
I need to know the best practice for doing such a scenario.
The best approach is usually to create a ViewModel type for your form. Add attributes to the properties of that model to define what would make it "wrong." Make your form use methods like #Html.TextBoxFor the various fields. Then have your PostMessage class take an object of that type, rather than taking the message and image name directly. Then you can validate the model and return the view again if the model is invalid.
See http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx for some code examples following this pattern.
You could specify the name of the view you want to return:
public ActionResult PostMessage(string msg, string imgName)
{
if (SomeErrorWhileSavingInDb)
{
// something wrong happened => we could add a modelstate error
// explaining the reason and return the Index view.
ModelState.AddModelError("key", "something very wrong happened when trying to process your request");
return View("Index");
}
// everything went fine => we can redirect
return RedirectToAction("Success");
}
Just redirect back to the Index action
return RedirectToAction("Index");
There are overloads for this method that allows you to pass route values and other information.