Today I successfully passed the 70-562 exam. I must admit that it was a challenge, and the time spent with preparation was more than useful. I earned 810 points of the available 1000, but it was more than enough to pass the 700 points limit.
As I suggested yesterday, you should definitely try and buy the MeasureUp package. The questions on the exam were rather similar. And be sure to read MSDN all day and night. I did so when I published these posts, but stumbled into classes and properties which I’ve never heard before. Anyway, at least they made the exam more than exciting.
You should be familiar with AJAX, the AJAX application services, and events. Be sure you understand the different IIS hosting models, and you are able to tell under which identity under a process runs (and on what this depends). Know how to set up and consume a WCF service, and understand ADO.NET. That was my weakest area, so currently I’m considering the ADO.NET MCTS exam (and the WCF one, too).
That’s all for now, I’ll post again when I know what will be my next exam.
When I search blogs for Microsoft Certifications (and even on the Microsoft Learning site), I constantly stumble into the name of MeasureUp. They say you should buy their tests, and don’t enroll to the exam unless you beat the test with a score of 100%, twice.
I must confess that I bought the sample test for 70-562, and failed so hard on the first time (when I considered myself as nearly ready) that I felt I must postpone my exam. So did I. But that was a month ago, and now, when I finished learning (some posts will come a bit later, I’m currently concentrating on the weak areas), I did that 100 per cent. Immediately after that I retook the test to see whether I can beat it again, and yes, I could (and did it for the third time in a row, just to make sure).
The point isn’t that I am so cool, but that all those blog entries and advices where right, you definitely should try and buy the MeasureUp questions in order to see some real hard stuff (the questions provided with the training kit can’t even be compared with the ones at MeasureUp). And even better, there are not just a single A or D as an answer, but explanations, sometimes paragraphs long. And from these explanations, I have (and you’ll) learned a lot.
So try it! It’s worth that money (and search for Coupon Codes on their site, to save more).
My exam is coming soon, I’ll write a little about it when I’m through.
There are two types of caching available in ASP.NET: page output caching and data caching. From the two, page output caching is the easier to use, so let’s start with that one.
Page Output Caching
Page Output Caching simply bypasses the page life-cycle by handling a cached version of the page instead of regenerate it from scratch every time. You can cache the whole page or a portion of the page nested into a user control. To enable page output caching, simply insert the OutputCache directive after the Page (or Control) directive on the page. OutputCache has the following parameters:
- Duration: the time in seconds to cache the page.
- Location: doesn’t supported in UserControls.
- Shared: sets whether or not the cached user control should be used in multiple pages.
- SqlDependency: a table in a database on which the caching depends on.
- VarByCustom: set up custom cache dependencies (set it in the global.asax)
- VarByHeader: a semicolon-separated list of HTTP headers to cache different versions of the page.
- VarByParam: a semicolon-separated list of query string parameters to cache different versions of the page.
- VarByControl: a semicolon-separated list of control IDs to cache different versions of the page.
In today’s post, we’ll explore the various state management techniques ASP.NET provides. But first we need to underline the fact several times that HTTP is a stateless protocol. Being so, it provides huge scalability, but the programmers need to find some ways to store data (even forms) between page requests.
ASP.NET has several answers to this question:
- View State
- Query String
- Custom Cookies
- Session State
- Application State
- Control State
Now I’d like to examine the first six, because I plan to give the topic of caching a full post, and profiles are a bit different from the others.
In this post, we’ll examine the built-in services in ASP.NET AJAX. You call these services in a same way as you’d call any custom web service from script, but there are some differences.
There are three built-in services in ASP.NET AJAX, namely:
- Authentication service
- Role service
- Profile service
To use these services, you must take two steps: first, configure that you’d like to call these services in your web.config file, then call the configured services from script in your pages. Both the configuration and the calling code is different for the three services, so lets get started with authentication.
In yesterday’s posts, we examined how to retrieve and process data from a database with the help of ADO.NET. Today, we take a look at the third major area of ADO.NET: XML.
I assume that everybody got this far already met with XML, some may also become quite fond of it (shame on me, but I haven’t), so I wouldn’t waste time to introduce it. Instead let’s get see what ADO.NET has for us. In this post, I will revise the following:
- Processing stream-based XML
- Processing in-memory XML
- XML data binding
- XML and DataSet integration
I’ll not going to describe LINQ to XML, since it isn’t covered in the exam, and even when you work with LINQ to XML, you’ll still need to know the basics of ADO.NET to perform for example basic XML data binding.
In the previous post, we discovered the connected layer of ADO.NET, namely the Command, Connection, DataReader classes. In this post, I’d like to review the disconnected layer of ADO.NET. The main classes are the DataSet and the various DataAdapter classes in this layer. But when should we use this one?
As noted previously, database connections are probably the most expensive resources in a given application. Therefore, it’s a good idea to use a limited number of queries for retrieving large pieces of data, than use numerous queries for little amount of data. The disconnected layer is built upon this theory. Large pieces of data (in fact, even a whole database) can be pulled to the client, then processed without the requirement of an open connection to the database. When the processing of data is completed on the client, it can send back the changes committed, and the database can be updated with these changes. Now let’s see the class that provides all of these features: