The 15 Benefits of High-Fiber Foods

November 28, 2012 § Leave a comment

How High-Fiber Carbs Keep Blood Sugar Down

The 15 Benefits of High-Fiber FoodsBy Pharmacist GeorgeCA

High-fiber carbohydrates break down slowly in your body and don’t trigger high sugar peaks. As a result, they trigger a lower insulin response, and a much delayed hunger response.

Foods with complex carbs also provide you with steady energy for your working muscles throughout the day and they are crucial sources of vitamins. Whole-grain breads and high-fiber food won’t make you hungry and can hold you for several hours because they break down slowly in your body and cause very little insulin to be released from your pancreas.

Benefits of Choosing High-Fiber, Low-Sugar Foods

Below are a list of proven benefits from selecting foods and beverages that are high in fiber and low in sugar.

  1. Stops the hunger cycle.
  2. Creates weight loss of up to a half pound per week (If you consume 35gm of fiber daily, you burn an additional 250 calories per day).
  3. Aids in long-term weight control.
  4. Can prevent or reverse heart disease.
  5. Helps you burn more fat at rest.
  6. Reduces stroke risk.
  7. Decreases cholesterol and triglyceride in the blood.
  8. Decreases fat absorption from the food you eat.
  9. Decreases sugar absorption from the food you eat.
  10. If you already have diabetes, consuming food that is higher in fiber content and lower in sugar, along with activity, helps you keep the fasting sugar levels below the recommended 110 mg/dl, brings diabetes under control and reduces the exhaustion to the pancreas’ capacity to produce insulin. This eventually may delay the need to use insulin later on.
  11. Helps you prevent diabetes complications.
  12. If you don’t have type 2 diabetes but are predisposed to getting it, consuming foods that are high in fiber and lower in sugar along with an active lifestyle, will help you prevent acquiring diabetes by making your pancreas get less exhausted in producing excess insulin.
  13. Makes you feel full.
  14. Keeps your bowels regular by its bulking effect (when drinking six to eight glasses of water daily).
  15. Reduces the risk of colon cancer.

Getting Enough Fiber

The daily fiber recommendations for good health is 35 grams. Currently most people are consuming on average about 10 to 14 grams of fiber daily. Remember that by increasing your daily fiber intake to about 35gm you will burn an additional 250 calories daily and you will get all the health benefits from fiber as discussed above. This is easily done. High fiber cereals such as Fiber One and Fiber Plus can provide you with up to 14 grams of fiber.

For lunch and dinner, eating high fiber carbs such as beans, brown rice or brown pasta (enough to cover a quarter plate) or two slices of whole grain bread will get you eight to 10 grams of fiber for each meal. Add on top of that five to 10 grams of fiber daily that you will get from the veggies and the fruits and you will be well over 35 grams of fiber daily. Don’t forget to consume five to seven cups of water, which helps fiber expand in your gut and exert some of its functions.

Examples of high-fiber or complex-carb foods are:

• Whole grain bread
• Oat bran
• Oats
• All bean products
• Lentils
• Peas
• Vegetables
• Fruits

Advertisements

Seven Secrets of Successful Pair Programming – John Sextro

November 22, 2012 § Leave a comment

Pair programming can be tough for even the best developers. It can be downright daunting if you haven’t done it before, are introverted or unsure of yourself. For those of you who want to improve your pair programming abilities, the following seven secrets are helpful strategies in accomplishing that objective. They are distilled from my 10 years experience pairing as a developer, technical lead, test driven development mentor and Agile coach.

Pair Programming Secret #1. Proficiency

Proficiency with the language and proficiency with the IDE are paramount to working as an effective pair partner. When you program with a pair partner you have nowhere to hide. All of your skills and abilities, along with your fears and shortcomings, will be on display for the team to see. To overcome these challenges, you must first accept that there will always be someone out there who knows more than you do.

Secondly, you should work to improve yourself in the places where you feel weak or unsure. Try spending 30 to 60 minutes per day, for a couple of weeks, on self-improvement in the areas you are worried about. You’ll be surprised by the results.

Finally, you must master your IDE. Almost all modern IDEs have a wide range of shortcut keys for the most commonly used actions and commands. Find a reference card for your IDE on the Internet and highlight the ones you think will be most useful to you. Then memorize the shortcuts and start using them every day. Your pair partner will appreciate your mastery of the IDE and you will improve your efficiency.

Pair Programming Secret #2. Communication

In any relationship, communication is key. Pairing is a very intense, albeit short relationship between two people working collaboratively towards a shared goal. Before you dive in to writing code, spend a few minutes discussing the task and identifying an approach to implement a solution. Doing so will ensure that you and your pair partner agree on what to do and how to do it.

When it’s your turn at the keyboard, keep your pair partner informed. You need to verbalize your thought process to let your pair partner know where you are heading and why. Try to articulate what you are doing and ask your pair partner questions to help keep him or her involved and engaged. For instance, after passing a test, I will often say, “What do you think?” and offer the keyboard. This is a chance for my pair partner to improve, refactor or write another failing test.

Pair Programming Secret #3. Self Confidence

When you are confident in yourself and your abilities, you feel comfortable offering and receiving constructive criticism. Self awareness of your strengths and weaknesses, coupled with a confidence that you “can do this” allows you to relax and focus on your work rather than on your shortcomings. Additionally, you will be able to open yourself up to constructive criticism and you will have the perspective necessary to determine if the criticism is relevant and actionable.

With self confidence, you will find that you are more willingly to ask questions and try out new ideas. Your self confidence can inspire better communication on the team by setting the example that you are willing to admit that you don’t know everything and are willing to ask for and accept help. When you’re self confident you don’t worry about what others are thinking about you or about your productivity, so you are more willing to take chances and try innovative solutions.

Pair Programming Secret #4. Self Control

The discipline of software development requires a significant amount of mental effort and focus. It’s easy to have self-control lapses when we are bored, tired or frustrated. Anything that distracts your attention can be a potential productivity killer.

The high-functioning teams that I have witnessed leverage their “team norms” or “ground rules” to help reduce the number of potential distractions. You can also leverage good Agile principles to stay focused. Use spikes to investigate new ideas and techniques. Add a “time allowance” to your spike story to keep from going down an endless “rabbit hole.” These are key because when you’re working on an Agile team you’re responsible not just for yourself, but for everyone else on the team. That’s what we mean by the “whole team approach.”

If you’re having trouble focusing, you should be able to rely on your pair partner and your team to help get you back on task. Just the same, if you notice that someone else is having a hard time staying focused, you need to be willing to step up and help them get back on track. Remember, you will succeed or fail as a team.

Pair Programming Secret #5. Patience

We have clearly established that writing code with a pair partner is very different from hacking alone all day. Your patience, or lack thereof, doesn’t usually affect others when you’re working alone. If you’ve spent your whole career as a solo “keyboard jockey,” pair programming will put your patience to the test.

As a pair partner you won’t always have control of the keyboard and mouse, and it is considered bad form to rip the mouse out of your partner’s hands. So when you get the urge to grab, take a deep breath, exercise your self control, and then use your best manners to ask, “May I?”

Once you get control of the keyboard and mouse, you should be willing to relinquish it without a fight. Liberal keyboard passing helps keep both pair partners engaged and motivated. Some of the best athletes in team sports are the ones willing to sacrifice a small personal victory and make a pass to a teammate in order to achieve a larger team “goal.”

Manners in the workplace seem to have gone the way of chivalry, yet good etiquette is a crucial part of human interaction. Programmers often forget this because they don’t have to thank their shell script for searching through a log file, nor do they have to ask their laptop to politely launch their favorite IDE. However, when pairing, good manners are expected and poor manners are not easily forgiven.

I find it useful to start off a new pairing session by setting a few simple ground rules. If you prefer to formalize these ground rules you can work with your team to create a set of team ground rules for pairing. Whichever way you go, just remember that it is necessary to have a shared understanding of how you will work together as a pair before starting, to avoid confusion and hurt feelings. You might be surprised to learn the actions that distract or bother your co-workers.

By working to improve your manners I think you will find that you will have more enjoyable pairing sessions and will become one of the most sought after people to pair with on the team.

Pair Programming Secret #7. Hygiene

This should really go without saying. Unfortunately, I have to say it because too many people ignore the use of basic hygiene in the office. It’s better that you hear it in the context of an article than suffer the embarrassment that poor hygiene could cause later. So consider this a quick “Health Class for Pair Programmers.”

Of course, you should shower every morning, brush your teeth and use deodorant. Throughout the day you need to be mindful of your breath and consider brushing, following up snacks and meals with a mint or breath freshening gum. If you smoke, you should always wash your hands and freshen your breath before returning to your workspace. If you cough or sneeze, be sure to cover your mouth using the inside of your elbow as a shield and sound muffler. Always keep hand sanitizer nearby to keep your hands clean and sanitary throughout the day.

In addition, if you work in a bullpen or Agile room, it’s important to remember to clean up after yourself. It’s not fair to the pair that will come behind you to have to clean up before they can start working.

Toward Pair Programming Perfection

Hopefully, you will find these seven secrets helpful for your next pairing session. I have probably violated every principle of every secret in this article and this is part of what has made it possible for me to compile these secrets. But thanks to my years of experience and with help from my teammates and coaches, I have gained a level of self awareness that now allows me to make the necessary adjustments to become a more effective pair programmer in the workplace.

By no means have I completed this journey, but I am a better pair programmer today than I was yesterday. It is for this reason that I define success, not as the attainment of a static goal, but rather as the continual attainment of small goals on a path toward perfection, and with the full awareness that my journey as a pair programmer will end well before achieving perfection.

Did I leave out any important traits for successful pair programming? If so, tell me about them in the comments below.

Why Testing Matters in Agile Projects

November 18, 2012 § Leave a comment

posted by Sharon Robson

Just like the passing of a monarch (the King is dead…long live the Queen) We are now hearing a similar thing in software development …”Testing is dead, we don’t need testers anymore!”….then……whoa!!, the customer is unhappy….then…….“Long live Testing”. But an even better, rounder, more effective testing. And like many resurgent monarchs through history (my favourite is Queen Elizabeth I), Testing will powerfully help redefine the way things are done and how they work.

I bet you are thinking that’s a big boast right? Well here’s how it’s going to happen….

Let’s discuss the concept of testing – what is it? Testing is the process of considering what is “right”, defining methods to determine if the item under test is “right”, identifying the metrics that all us to know how “right” it is, understanding what the level of “rightness” means to the rest of the team in terms of tasks and activities, and assisting the team make good decisions based on good information to hit the level of “rightness” required.

Testing is way beyond random thumping of the keyboard hoping to find defects; testing is about true understanding of the required solution, participating in the planning of the approach taken to deliver it, understanding the risks in the delivery methods and how to identify them as soon as possible to allow the appropriate corrective action to be taken. Testing is about setting projects up for success and helping everyone to understand the appropriate level of success required.

So why do we still care about testing, isn’t everyone in the agile team doing it? Well, actually NO!!

It all begins with the concept of quality. “That’s easy” you say to yourself, and if you do I dare you to take it to the next step….define it! Ask your development team, ask the customer, ask the Product Owner, ask the Project Manager, ask the CIO and CEO of the organisation to define quality, define good, define good enough. Do they agree? If not there is your first problem. The role of testing is there to help teams define and understand the impact of quality.

“Impact of quality?? What is that?” is your next question. Here is a fact – Quality costs! But even worse – true quality cost more! To build it in we first have to define it and then find it. There is no way to have a quality solution without building the quality into the process, the techniques and building thorough testing, at all levels, into the work that we do.

“Gotcha!” says the devs “We define done to tell us about quality in agile”. “Rubbish!” is my reply. In all my time in IT the most exciting concept I ever heard of was that of defining “done” – all the components, all the knowledge gathered, all the information passed on….the complexity of the solution defined up front, all the team (development and customer teams), being aware of the work to be completed to generate “done”. Defining done reminds me of what testing is all about. But the bad news is that we don’t do it! No! We don’t! Just like we don’t define quality…we just pretend we do. Ouch! Did that hurt?

Why did I say that? Firstly, the definition of done, like quality is very difficult. Quality is like beauty – it is in the eye of the beholder. Testing is all about being trained to focus on the definition of and then the detection of quality (or the lack of it) and also communicate what the quality levels mean across the project in terms of progress, risk and the work remaining. Defining done is the same really…done is in the eye of the “doer” (not the beholder) and this allows us to understand the many levels of done…done (my bit), done (our bits), done (the story), done (the iteration), done (the feature), done (the release), done (the product), done (the project).

“Well that’s ok, we can define when it’s finished” is your witty response to this problem. Now here is the challenge! Defining “done” is very different to defining “done well”. The “well” bit of “done well” is not only about finishing the work required for the thing under production, but for also defining how we will know that it is finished to the standard required. Each level of done has a different standard of completion and a very different standard of quality of the “well”. There is one group of people inside a team who are ideally suited to not only assisting in defining “done well” but also the process and techniques that can be used to find the degree of “well doneness”.

Step one, define finished…well that seems easy – make sure that all the components needed to deliver the level of done have been completed by the doer. Ok, sounds good so far. But here’s the rub…nothing is “done” until the customer is happy with the product. That is one of the underpinning attributes of the Agile Manifesto. I quote “working software over comprehensive documentation”. For some unknown reason the definition of “working” got confused with the definition of “done” and the concept of “comprehensive documentation” got confused with the definition of well tested. And then this is trumped with the principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. So what makes software valuable? Is it that the product  is there? No! it is that it does its job well!! So is this done (my bit), done (our bits), done….?

So how can we do it? For a start we need to recognise that testing considers more than just the functionality which is where the developers and the users focus. What it “does” is the easy bit (tongue in cheek – I promise). It is easy to define, easy to build, easy to assess. Functionality tends to be binary….like done! There are two levels of done…”Done” and “Not Done”….there is nothing like “almost done”. Functionality is like doneness….it functions or it does not….binary! But then we get into the realm of “done” and then “done well”, and then even further “done well for whom?”

Testing focuses on understanding what makes a solution or an approach valuable to the people using it. Value is context dependent and has to be defined in the context of the project and the customer. Using standards such as ISO9126 with its 6 quality characteristics (functionality, reliability, usability, efficiency, maintainability and portability) with their sub characteristics allow the testers to provoke great discussions around what is good and well and valuable. But even better true testing is needed to find these attributes. This type of testing also takes time and planning to do well, and even longer to do very well.

All the non-functional attributes of a solution are design level attributes and usually cannot be evolved iteratively. They need to be discussed up front, as soon as possible in the definition of the solution and yes….as soon as possible in the definition of the design of the solution. If these attributes are not built in right from the beginning they will never be able to be found through testing at the end. Can unit testing do that? No!

“Ahhhh – that’s why we do Acceptance Testing Driven Development!” You say. I agree, but we don’t do ATDD properly, we only focus on what the customers know about and ask about, not about the things that are needed to be thought about and captured early.

“Let’s just focus on the functionality” is a phrase I often hear that causes me to cringe….it means that it is too hard to think about anything else so let’s just get going and hope that it is right. Have you EVER heard of anything LESS agile? Agile is about building it right, the first time!

Testing contributes to this building it right, the first time, via static testing. Static testing is “testing the solution without executing the code”. The beauty of static testing is that it can be done anywhere and at any time. Static testing should happen when someone comes up with the first idea for a solution. Ideally a tester is there saying things like “that’s interesting functionality…how will you know it is valuable?”. Testing the concept to see it will actually deliver the required solution through questions, diagrams and the planning of the solution is a vital part of the life of a product.

We can also test the planning of the delivery, focusing on risks and the timing and dependencies of the components and then how the various levels of “done” can be used to prove that we are all heading towards the right solution. Defining done to the extent of defining “well done” requires the engagement of the right people at the beginning of the work, not after the code cutting has started. Testing the plan is vital – have the right environments, teams, resources, approaches been defined to deliver value? This is often a question that is NOT answered prior to code cutting beginning. The wonderful new regime of Testing being alive and well sees it being asked….AND answered prior to anyone moving to the next step.

This is best achieved by the up- front definition of acceptance criteria – using test design techniques. “WHAT??? Testing already???” you yell. Yes, of course! What is the value of all the training and certifications that testers achieve if they don’t apply it up front? Most of the test execution activities that you see testers do are as a result of their test design activities based on risk and specification based test design techniques. Concepts, features, epics and stories are just specifications masquerading under another name. Even better, in the ideal agile world, testers are involved in their definitions so that they are able to be statically tested and then have dynamic techniques applied to them prior to anyone attempting to cut a line of code.

So then we start the real work (chuckle….anyone who thinks that what happens before code cutting isn’t work does not understand the concept of work), We start to cut the code, do unit testing, promote the code, do integration testing, promote the code to the test environment all in the hunt for (drum roll)……Emergent Behaviour!

Emergent Behaviour  – This is the true value of the testers in an agile team, focusing on how the modules and code and stories hang together to deliver the required functionality. But we all know this is where the good bugs live! Bugs that only show their heads when we start moving through the solution in various ways. The skill of the tester is to design those paths through the system following both the customer’s needs and also the risk of the path, using test techniques to identify key areas of focus. This is where the skill in using Decision Tables and Finite State Models (such as N-1 switch coverage) really come into the fore. These are the bugs that won’t be found at unit or integration test time, but will cripple the acceptance testing immediately.

The process of system testing, designing tests to promote risky emergent behaviour and also designing tests to provide the empirical evidence required to assess such things as coverage, residual risk, defect density, progress rates, and other quality attributes is also the skill of the tester. I would not suggest that developers or BAs cannot do this. I would suggest however that they are way too busy doing their jobs! I would also suggest that the testing mind set and skills are best to be effective and efficient in planning, executing and reporting these things.

This brings us to the discussion of Validation and Verification. What’s the difference? Verification is making sure it is built correctly – adhering to standards, following patterns, doing the right thing at the right time. Validation on the other hand is defining what is the right thing! Both of them need to be done, and testing gives us the skills and techniques to do both, as well as do them to the various attributes of the system that need to be covered (such as the quality).

The next question is “do we still need testers?” IMHO – yes!!! Why? The testing practitioners think differently to everyone else on the team. Testers are “professional pessimists” (ISTQB Foundation Syllabus). Good testers spend our time focusing on the potential problems, not the potential solutions. Right from the beginning we consider the bad news  – what could go terribly wrong, and how quickly can we find it, or even better, what can we do to stop it? This fits perfectly with the agile concepts of “failing fast” and understanding the risks as soon as possible. We need this mind set engaged as soon as possible in the project and solution design to identify as many of the potential hurdles as soon as we can.

Not many people know enough about testing to be able to accurately plan the testing effort, and in an agile team the focus on where and when to test stuff is huge! There needs to be a clear line between story level testing, iteration level testing and feature level testing; remember the levels of “done” from before? Who and where and when each of the tests need to be done needs to be clearly defined to ensure that all the environments, tools, techniques, data and people are available to execute it. Testing (like most things) does not happen by accident in good teams…good testing takes great planning. Great testing takes excellent planning. Testers and testing need to be intimately considered in this planning to make sure all the appropriate set ups are established and put in place.

“How do testers do that?” you ask? Most people only think of testing as test execution, but in the real world the bit of testing that you see is the bit of testing that is the easiest. Executing test cases takes about 25% of the total test effort. Most testing is done in the mind or in documentation. “OMG”….you are shocked…..”Agile says “working software over comprehensive documentation”! Yes it does! But testing can happen on any and all documentation (stories, whiteboard designs, acceptance criteria etc). The first and biggest hurdle of all is people or teams who do not want to define “well, value, done” or don’t want to get into specifics because it is too hard.

Blended teams allow us to have the best of every world, deliberately excluding a skill set or knowledge set is naïve and truly immature behaviour and does not promote longevity of solutions or longevity of the approach. An integrated team that covers all the skills required to deliver the best possible solution in the best possible time for the best possible price is just plain smart and good business. Recognising the skills of the other people in the team and leveraging them to their maximum is also just plain smart.

Do testers need to be a special group of people? No….anyone can be a tester on an agile project, in fact everyone is a test executer on an agile project. The main thing is that all the team members  have the discipline to ensure that they have put their “testing heads” on during the day to day work to complete all the testing activities (not just execution) that are required. If team members don’t take the time or make the effort to plan, design and then applying testing to their work products, to their approach and their solution then the team will have no idea of the progress they are making and the issues that they are facing.

So what advice can I leave you with:

  • Make sure your whole team has a clear and shared understanding of the definition of done at every level – my task, the story, the iteration, the release, the project and the product
  • Make sure your whole team has a clear and shared understanding of what quality means on this product – what constitutes “working software”
  • Testing is not bashing a keyboard hoping to find defects, nor is it just running unit tests
  • Testing is a whole team responsibility, that should start with the very first concept discussions and pervade every aspect of an agile project
  • Test early, and test often – waiting until the end of any piece of work is the wrong time to start thinking about testing
  • Static testing (examining every piece of work to ensure it contributes to the quality needed) is more valuable than executing test cases
  • Designing good tests is a specialist activity, all members of an agile team can do it but it needs the right mindset

Is testing dead in agile? Yes….traditional, old fashioned, end of the lifecycle testing is dead. Long live the new testing, integrated, up front, actively involved, challenging mind sets, challenging the status quo and enabling the team to deliver…deliver Value, deliver “working software” and deliver solutions that customers actually want!

Bugs Cost U.S. Economy $60 Billion Per Year

November 14, 2012 § Leave a comment

Interesting article I read posted by Bradley Jones… That I want to share and put in my blog

The cost of bugs in an infographic that Typemock created. I’ve included this infographic and a link below.

As you can see, bugs and defects in software can be extremely costly to an organization — to the level of $60 Billion (US) dollars a year. That’s about $113,333 a minute. Fixing bugs earlier is obviously cheaper. Take a look at the infographic. It has a lot of interesting statistics including the stat that agile projects are 300% more likely to succeed thank non-agile projects. Ironically, the statistics don’t show how much more likely an agile project is to have a bug…!

The Severity of Bugs: Are We Doomed Infographic

Creating a simple application using MVC 4.0

November 5, 2012 § Leave a comment

Source : Code Project

 

Introduction

In this article, we will understand what is MVC and create a simple application using Model, View and Controller.

Model View Controller: MVC is a software architecture, which separates the logic from the user interface. This is achieved by separating the application into three parts Model, View and Controller. MVC is separation of concern. MVC is also a design pattern.

Model:Represents the logical behavior of data in the application. It represents applications business logic. Model notifies view and controller whenever there is change in state.

View: Provides the user interface of the application. A view is the one which transforms the state of the model into readable HTML.

Controller: Accepts inputs from the user and instructs the view and model to perform the action accordingly.

Advantages of MVC:

  1. Full control over HTML rendered. No renaming of HTML IDs
  2. Provides clean separation of concerns (SoC).
  3. No ViewState (Stateless).
  4. Enables Test Driven Development (TDD).
  5. Easy integration with JavaScript frameworks.
  6. RESTful URLs that enables SEO. Representational state transfer URLs example User/Comment/1, which is user friendly, no URL rewriting required.
  7. Integration on the client side becomes easy like using JavaScript, JQuery, Ajax, JSON….
  8. Supports multiple view engines (aspx, Razor)

Creating a simple application:

Step-1: From file select project and select MVC 4.0 application

Step-2:Select the template and view engine (Razor, ASPX, NHaml, Spark). If want to include test project check the option “Create unit test project”

A solution with following structure is added.

Build and run the application, you can see the home page of the application. By default we have Home, About and Contact section added.

Let’s add our own Controller, Model and View for showing User’s details. Right click on Model and add a class with the name UserModels.cs with the following structure:

Now let’s apply validations on the fields:

  • Required: To make the field value mandatory.
  • StringLength: To set the maximum length of the field.
  • Range: To set the minimum and maximum value.
  • DataType: To set the type supported by the field.

Let’s add some default data to our view. For that we will create a class called user and initialize with some default value.

Now let’s add methods for Adding, Updating and getting list of all users.

Now let’s add view for our model for that we will select strongly-typed view and select our model class. You can see list of scaffold templates available. Since we are creating this view to add a new user we will select Create option.

The moment we click on Add, below is the cshtml created for the view

We can see the view is having all the fields set in the model along with the validations applied on it.

Now let’s add a controller for our view. Right click on controller folder name our controller as User, select Empty MVC controller and Add.

By default our controller contains an Index method. Right click on the index method and add view for this. Index method can be used to show the list of user’s available. So we can select scaffold template type as list.

Once the view is added for Index and UserAdd, we have to define its get and post method in the controller. By default its always get, if we want a post method we have to define [httppost] before the method declaration.

HttpGet: will render the form and HttpPost will post the form data. For example we need to add a new user. First we need the form to add a user, that is get and when we will the form with values we need to post those values, so that it can be saved for further access.

Look at our controller structure, it contains two get methods, one to get the list of users (Index) and other to get theUserAdd form and with the same name it contains its post method.

ActionResult: An action result represents a command that the framework will perform on behalf of the action method. The ActionResult class is the base class for action results. Common return Type:

ContentResult: Can be used to return plain text or user defined content type.

 Collapse | Copy Code
public ContentResult Test() 
{
    return Content("This is my test data");
}

JsonResult: Used to return JSON, mainly used for Ajax request.

 Collapse | Copy Code
public JsonResult Test() 
{ 
    return Json ("This is my test json data");
}

PartialViewResult: The PartialViewResult class is inherited from the abstract “ViewResultBase” class and is used to render a partial view.

 Collapse | Copy Code
public PartialViewResult Test() 
{ 
    return PartialView("Result");
}

ViewResult: It renders a specified view.

 Collapse | Copy Code
public ViewResult Test() 
{ 
   return View("Result"); 
}

FileResult: It is used when we want to return the binary content/file as an output.

RedirectToRouteResult:  It is uesd when we want to redirect to another action method.

JavaScriptResult: If we want our action method to return a script that can be executed on the client side we can use this type.

Three new types which are supported from MVC 3

1. HttpNotFound: This returns 404 error on client side. It can be useful in situations where the resource is not available and we want to display 404.

2. RedirectResult:  It can be a temporary or permanent return code 302 depending upon the boolean flag. Can be used to redirect to the given URL

3.  HttpStatusCodeReturn: It can be used when user want’s the choice of error code to be returned from the action method. It can be any code.

Routing with MVC: 
MVC gives great flexibility for adding user friendly URL’s.  Routings are defined under the class RouteConfig. By default one route is already defined.

MVC routing pattern include {controller} and {action} placeholder. For more details on routing please refer this linkhttp://msdn.microsoft.com/en-us/library/cc668201.aspx

This is how our index page will appear with the URL:

And the UserAdd method, here controller is User and Action is UserAdd.

Points of Interest

More keen in learning MVC 4.0 new features. Lets learn to build a simple application then we can move ahead with advanced features.

Where Am I?

You are currently viewing the archives for November, 2012 at Naik Vinay.