I have a Web Reference to a remote Web Service, which is called in several different classes. I'd like to catch all exceptions coming from this Web Service only.
How can I do that (for example extending it's base, auto generated class) without interfering and modifying all upper level code?
You can't, and why do you want to? It's almost always a mistake to "catch all exceptions" or "handle all exceptions". What are you trying to accomplish?
I'd suggest you log it on the server, not the client.
What will you be doing when you hide the exception from the upper layers? Pretending it didn't happen?
It might make sense to wrap the SoapException in one of your own. Maybe. That's only because SoapException is so specific to web services. In this case, yes, you need to wrap every call in a try/catch. The best way to do this would be in a facade class, which could also have the common code for wrapping the SoapException or translating it into one of your own.
Still, unless you're ready to take control of the code generation, you'll wind up doing this by hand.
Related
In one of my views, I have a ViewModel which I populate from two tables, and then bind a List<ViewModel> to an editable GridView (ASP.NET Web Forms).
Now I need to send that edited List<ViewModel> back to the Services layer to update it in the database.
My question is - is it Okay to send the ViewModel back to Services, or should it stay in the Presentation? If not - should I better use a DTO? Many thanks.
Nice question !
After several (hard) debates with my teammates + my experience with MVC applications, I would not recommend to pass viewmodel to your service / domain layer.
ViewModel belongs to presentation, no matter what.
Because viewModel can be a combination of different models (e.g : 1 viewModel built from 10 models), your service layer should only work with your domain entities.
Otherwise, your service layer will end up to be unusable because constrained by your viewModels which are specifics for one view.
Nice tools like https://github.com/AutoMapper/AutoMapper were made to make the mapping job.
I would not do it. My rule is: supply service methods with everything they need to do their job and nothing more.
Why?
Because it reduces coupling. More often than not service methods are addressed from several sources (consumers). It is much easier for a consumer to fulfil a simple method signature than having to build a relatively complex object like a view model that it otherwise may have nothing to do with. It may even need a reference to an assembly it wouldn't need otherwise.
It greatly reduces maintenance effort. I think an average developer spends more than 50% of his time inspecting and tracking existing code (maybe even much more). Now everybody knows that looking for something that is not there takes disproportionally much time: you must have been everywhere to be sure. If a method receives arguments (or object with properties) that are not used directly or further down the call stack you or others will walk this long road time and again.
So if there is anything in the view model that does not play a part in the service method, don't use it to call the method.
Yes. I am pretty sure it is ok.
Try to use MS Entity Framework and it will help you allots.
I'm about to implement a web service for my database, perhaps using WCF Data Services. Some of the objects I need to make available have child objects that need to be present for the objects to be useful. But because of lazy loading in the Entity Framework, those child objects are not going to be automatically loaded.
I'm going to be calling this service using JSON, and I don't want to have to specify the $expand option in each call. And it's not clear to me where I would use the LoadProperty method (same link), since I'm just writing the InitializeService method and letting the framework do the rest.
Is there a way to configure it to explicitly load some child objects and not others?
WCF Data Services currently doesn't support auto-expand on the server. The client always has to ask for expansions.
You could implement some kind of a workaround around the WCF DS, by modifying the incoming request. So for example if the client sends request for ~/Products you could modify it before it gets to WCF DS and let it process ~/Products&$expand=Category and that way effectively achieve auto-expand. But for such a service to be robust, you would have to parse the query URL and only add the expand if there's not already one in there and so on.
The other way is if its always necessary for the child object to be present, can we make the child object complex types instead of entities, so that they always come along with the parent. Is there a strong reason for the child objects to be individual entities?
Hope this helps.
Thanks
Pratik
Folks,
I have an application that is primarily one page with a lot of user controls and custom controls. ASP.Net WebParts are being used. There is almost no code in the web page and its master page: it's all in various components.
The design requirements include an error message display panel. The client would like the app to display any errors occurring in any part of the app on the error message display rather than going to a custom error page. (This was a recent decision: when we started we were thinking custom error page.)
As far as I can tell, WebParts don't provide any default error handling (no capture of errors and displaying of messages) and user controls don't necessarily fire their OnError event when an internal error occurs.
So I'm looking at wrapping absolutely everything in Try ... Catch blocks, at least at the presentation level, and doing the handling. So my question is: is there any easy way to implement a kind of global, or at least class-wide, error handler, that will handle an error in the way I choose, interrupt the routine that was executing, but return (after handling) to the caller of the method that failed?
I'm willing to adapt code to verify that subroutines did what they were supposed to and returned appropriate values (ex: non-null data objects.) What I don't want is for the whole process to be aborted up to the very top, with rendering skipped, or (of course) the famous yellow and white screen.
I guess this is a case for aspect-oriented programming, but I don't think ASP.Net provides anything like that yet. I didn't get the impression that EntLib 5.0 did, either.
I would adore it if it were possible to decorate a method with an attribute that meant "On error call such-and-such a static method of such-and-such a class". But I doubt it is, yet.
Any suggestions are welcome.
Thanks,
Ann L.
For starters, it's bad practice to put Try Catch handlers around every piece of code in your application. There is a slight performance hit every time you set that up, and this could slow things down really fast.
In your Global.asax.cs (or .vb) file, there is a method in there called Application_Error which is the global error handler. This will catch any error you haven't previously caught (or thrown up) within the application.
You could easily put your error handling code here. It could be as simple as dumping the error message to a log for future review, or check for the exception type (SQL vs. File vs. HTTP) and do the error handling task related to the type.
You need to take a look at elmah. If you google 'elmah' it has an error module/handler that does pretty much what you are looking for (although it will take some extra tweaking..)
You might want to consider letting your errors 'bubble up' though.. There are some serious performance issues with writing a bunch of Try..Catch..Finally blocks...
I am currently trying to use the "Invocation tags" of Mate to call my web services and delegate the WS-responses to my fault/result handlers.
I want to use the generated proxies, provided by the Flex Builder, and not the plain <WebService> or <WebServiceInvoker> tags.
I actually failed using several techniques:
<WebServiceInvoker> does not work with the generated proxies.
<AsyncMethodInvoker> needs some complicated successType that I could not get to work with the WS-calls. And defining the events seems redundant to me. I want it simple and easy to read, the code will be touched by other people than me!
<MethodInvoker> can't use instances, and it also can't handle the proxies' AsyncToken
<DelegateInvoker> Looked fine at first. It calls the service but doesn't fire valid result events (infinite busy cursor). Even though i can successfully bind to the XYZ_lastResult of the WS-proxies, and a WS-call results in getting valid data from the WS-backend, the <faultHandlers> and <resulthandlers> are not executed. There is some solution for the DelegateInvoker that changes code in the generated proxies, which i definately do not want to do!
So here is my question: Is there a simple(!) way of using default Flexbuilder generated proxies with the Mate Invocation tags?
It appears that your request is not that uncommon to Mate. Check out this couple of threads in their forum:
http://mate.asfusion.com/forums/topic.php?id=424
http://mate.asfusion.com/forums/topic.php?id=421
The solution is to modify some bits of the auto-generated code... which in a way ruins the whole point of using code generation.
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.