SOA stands for Service Oriented Architecture with SOA pretty much you do things with services.  Wikipedia defines SOA as:

an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications. SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. The concepts of Service Oriented Architecture are often seen as built upon, and the evolution of, the older concepts of distributed computing and modular programming.

A simplistic way I like to "think" of SOA is your main application doesn't actually manually touch any of your data.  Instead you go through say web services to get and do all of your data-centric stuff.  One major reason being I can then build my application or my services in any language I want and just access them through a specific protocol.  To find out more about SOA please read the wikipedia article.  I just wanted to give you a basic concept of SOA. 

C.R.U.D.

CRUD stands for "Create","Read","Update", and "Delete". They are the 4 basic things people typically do with data in a some type of data store. Wikipedia defines CRUD as:

Create, read, update and delete (CRUD) are the four basic functions of persistent storage, a major part of nearly all computer software. Sometimes CRUD is expanded with the words retrieve instead of read or destroy instead of delete. It is also sometimes used to describe user interface conventions that facilitate viewing, searching, and changing information; often using computer-based forms and reports.

Often when working with data these are the 4 basic steps that are required to work with the data. So when you are creating your backend make sure you have at least these 4 things and you are set to start working with data.

This post is the first in a series of posts one what acronyms are in the programming world as there are a lot and we all need to know them so we don't get lost.

Part 1: Write to XML File Using C#
Part 2: Reading Data from XML File Using C#
Part 3: Delete Data from XML File Using C#

In the last post on XML, Reading Data from XML File Using C#, we retrieved our data. The only thing we really have left to do is delete data.

I am going to leave updateing data to you to figure out. With these 3 main posts it should be enough for you to figure out how to update data. If not please feel free to leave a comment and I will go ahead and make a post on it, eventually.

The Code

How about we step through this short amount of code. Please, if you haven't taken a look at the other two posts I stongly advise you to.

public void DeleteContact(string theGuid)

In Write to XML File Using C# we mentioned the Guid was going to be used to find unique data to delete out of the xml file, similar to a database. Here we are taking the guid as a sting parameter to compare to all the others guids that we get from our xml file.

XmlNode rootContacts = doc.SelectSingleNode("//contacts");
XmlNodeList nodes = rootContacts.SelectNodes("contact");

Briefly, this gets the main contacts node and takes all the main nodes under that and adds them to a list that we can iterate through. This is explained more in: Reading Data from XML File Using C#.

for(int i = 0; i < nodes.Count; i++)

We are setting up a basic for loop to iterate through our list. We are using a for loop because we can't delete anything out of a list while using a foreach. We start at 0 since most collects start at a base of 0. We are using i < nodes.Count because the "Count" is the total number of objects in the collection and starts at 1 so we don't want to include it with <=.

if(nodes[i].SelectSingleNode("Guid").InnerText == theGuid)

This code is comparing the text of the node Guid inside of the contact node to our parameter we passed to the method.

rootContacts.RemoveChild(nodes[i]);

If the 2 guid's are the same then this line of code deletes that contact node as a whole.

doc.Save(_path);

Again this just saves the current xml file, but this time with the data gone.

Wrap-Up

This was a quick post on how to delete data. If you have followed along with Part 1 and Part 2 then this should be pretty simple. If you haven't looked at them please do.

Any questions, comments, or suggestions are welcome please leave a comment.

XmlAccess.zip (2.22 kb)

I haven't blogged anything in the last few days and I just wanted to show you the reason why. I have spent quite a bit of time playing with my new toy and in some respects member of the family.  It is a 2004 Rocky Mountain Edition Jeep Wrangler 4.0L Inline 6.  Follow the link to see all the pictures of my 2004 Rocky Mountain Edition Jeep

Now that I have shown you why I haven't been bloggin maybe you can forgive. I hope to have a couple new posts by end of the day on Christmas.

Tonight I am at the Tulsa Developers .NET user group meeting. Our speaker is Ron Jacobs talking about the Model View Presenter pattern for us .NET people. It is an interesting talk on how to build a calculator using the pattern. You can download the code off of his site and take a look.

Please enjoy a couple of pictures from the event and please excuse the bad quality of the images it is from my camera phone.

Part 1: Write to XML File Using C#
Part 2: Reading Data from XML File Using C#
Part 3: Delete Data from XML File Using C#

In the last post, Write to XML File Using C#, I talked about our XML document and how to write to an xml document. Doing so is fine and dandy, but useless if we can't read it. If you want to know about the xml file and some of the information surrounding it please visit the Part 1: Write to XML File Using C# to find out more. We are going to just jump right on in to the code.

The Code

Lets step through this code.

public List<Contact> RetrieveContacts()

This line is our method declaration we are basically going to end up with a list of contacts to give for our application to use from our XML file.

List<Contact> list = new List<Contact>();

This is the list object we are creating and going to return back at the end of the method. An easy very simplified way to look at a List<> object is as an array that holds a bunch of other objects of whatever type you need it to be. I just basically think of them as an array that I can use; there is more to it, but I'm not advanced enough to reap the benefits.

XmlNode root = doc.SelectSingleNode("//contacts");

This is getting the top level node of the xml where all the contacts are below it. So that in the next wine we can grab all the contacts.

XmlNodeList nodeList = root.SelectNodes("contact");

I like this line of code it is kind of fun in what it does. In this case we are creating a list to get a collection of objects. Or this it grabs all the contact nodes and puts them in an object for us to get the information out of.

foreach (XmlNode n in nodeList)

The foreach loop is one of my favorite loops because once I "grok'd it" it was a lot of fun to start using. What the foreach is doing is saying hey I have an collection here with a bunch of objects in it. I want to go to every single object in it until I get to the end and perform some operation. So in the case of this one it sees that there is an object with a bunch of contact nodes in it. So it is going to go to each contact node and do something.

Contact c = new Contact();

We are creating a contact object because that is what our list object takes that we are going to return at the end of the method. From here we are going to populate the information in the contact object and add it to our list object.

c.GUID = n.SelectSingleNode("Guid").InnerText;
c.Name = n.SelectSingleNode("Name").InnerText;
c.Email = n.SelectSingleNode("Email").InnerText;
c.PhoneNumber = n.SelectSingleNode("PhoneNumber").InnerText;

With these lines we re taking the contact object we just made and adding the information from the xml file, but going into the contact node and selecting a specific node and grabbing the text between the <></>

list.Add(c);

This is the very last line of our foreach loop. It takes that contact object we created and adds it to our main list object.

return list;

Finally at the last line of the method. Here we return that list object to the main part of the application for it to be used.

Wrap-Up

Alright lets go through a paragraph explaining it top to bottom.

First, we created the method which in the end is going to be a list object that holds a bunch of contact objects for our application to use. We proceed through the method first creating our main list object. We then proceed to get the top upper level node out of the xml file that holds all of our contact nodes. Once that is done we take that information and get all the contact nodes and put them in to NodeList object to be used. We then make a contact object fill in the relevent properties from our contact nodes and add it to our main list object. From there we return the list and now our method call is a list object full of contact objects for us to process.

This wraps-up basic reading from an xml file. Only thing really left is deleting data from an xml file.

Part 1: Write to XML File Using C#
Part 2: Reading Data from XML File Using C#
Part 3: Delete Data from XML File Using C#

Often times people want to write out information to a file instead of a database. Problem is xml is hard to understand at times and code samples aren't much better. I am going to do 3 or 4 posts on how to do basic interaction with an XML file.

Usually the most important part about using an XML file is first writing to it, but how can you write to it if you don' thave an XML file? Below is a basic XML file I have come up with that we are going to read, write and delete from along with an explantion of the XML file.

The XML File

The concept behind this xml file is first you have the root node, everthing <> is pretty much refered to a node or element (we will use node). The root node holds EVERYTHING in the xml file and can be your starting point if need be. Next is the contacts node that will hold each individual contact and their information.

Next we get to the meat of the xml file. The contact node. There will be, in the case of this xml file, multiple contact nodes with "Child" nodes. Basically, the contact node will have nodes which contain all the information. I look at xml files kind of like the earth. You have your innercore which is you main information, but it needs to be surrounded by the outercore. Then you have the mantel which surrounds the outercore followed by the crust of the earth, everything is layered. Same with XML I have it pictured in my head in layers and everything needs to be accessed in those layers in order.

Constructor

First, lets look at the constructor of our first class. I usually just create a class that handles all the data read, write, and delete stuff. Lets call it DataAccess.cs. At this point create a basic console project and add a DataAccess.cs class to it, and an xml file with the above xml. Here is the constructor I use to start to start with the xml processing. (note: localpath is cut off because it is long)

In the above code we have the private datamembers and the constructor. I'll explain the code line by line.

private string _path;

Here we have a string that is going to be use for our full path to the xml file. When I say full path I mean name of the file and the location on the harddrive.  So we could potentially have C:\folder\file.xml

private string _localPath = @"The_Path_to_the_project_folder_with_xml_file_";

In this line we are hardcoding the path to the folder where the xml file resides. Doing it this way in real world applications is bad instead use a configuration file, like an xml file, to get the information and set where the xml file is. Hardcoding paths is bad.

XmlDocument doc;

For this snippet of code you should have a "using System.Xml;" statement in your using directives. What this code is doing is setting up an object that is going to hold our xml information so that we can access that information. In the constructor is where we are going to add all the xml to this object.

public DataAccess(string xmlDocumentName)

This is the constructor that will take in the name of the xml file we want to use. So in the case of our xml file it will be "Contacts.xml".

_path = _localPath + xmlDocumentName;

Here we are populating the full path of the xmlfile with the absolute location and the xml's filename. It might look like C:\XMLProject\bin\debug\Contact.xml if you were to write out what it was.

doc = new XmlDocument();

Here we are initializing this object and allowing it to start being used by the rest of the code.

doc.Load(_path);

And this is our magical line. This takes that xml file that we got the name and location of grabs all of the xml from the file and pops it into the XmlDocument object named doc. With that we are ready to start messing with the XML.

Code to write to an XML file

Alright the fun part as arrived actually writing your data out to the xml file. It is actually a fairly simple thing to do once you understand what is going on so lets get started.

public void AddContact(Contact contact)

Just threw a curve ball at you. I have a contact datatype specified as a parameter. This is something that I created. It is a non-static class that has 4 properties in it GUID, Name, Email, PhoneNumber. I'll post the code at the end. I use an object like this for simplicty sake. Instead of passing in 4 or 100 parameters I can pass in an object like contact that can have any number of properties and I only have to pass it alone. Later in the code I think you will understand better.

XmlNode newContact = doc.CreateElement("contact");

Here is where we start building out our planet. We are creating at this point our "OuterCore" which will hold the innercore which is the data we want. This node is going to be what we add to xml file. In the method call of CreateElement we are passing it a string called contact. If you look at the xml file you will see this is the container for the main contents and it is namec contact (note case). You should treat xml as case sensitive.

XmlNode guid = doc.CreateElement("Guid");
XmlNode name = doc.CreateElement("Name");
XmlNode email = doc.CreateElement("Email");
XmlNode phone = doc.CreateElement("PhoneNumber");

Here we are creating more XmlNodes each with their own name that will be in xml file. Next we will actually add the data.

guid.InnerText = System.Guid.NewGuid().ToString();
name.InnerText = contact.Name;
email.InnerText = contact.Email;
phone.InnerText = contact.PhoneNumber;

Here we are setting the InterText property to what is in the contact properties. Think of them as the parameters we passed in. Also note the guid is being created on its own. When we save out the xml file what ever is in the innter text propery will be data stored so you can look at it like this

<Node>InnterText</Node>

Next chunk of code

newContact.AppendChild(guid);
newContact.AppendChild(name);
newContact.AppendChild(email);
newContact.AppendChild(phone);

This code might look a bit confusing, but this is what I call packaging your data into one object. Every XmlNode can have childnodes attached to them. In this case the child nodes are the inner core or the xml at the level below contact node. So we need to package everything together and get it ready to add to the main file. So that is what this code does. It goes to the last element if there is one and adds the node there.

doc.SelectSingleNode("//contacts").AppendChild(newContact);

This is what we have been waiting for adding the data to the xml file. So since we packaged all of our information into the contact node inside the newContact object. All we did here was find the contacts node which is the mantle and attached the outercore to it.

doc.Save(_path);

This is pretty much is easy to guess. It actually saves the data to the xml file for us to use at a later date.

 

The following is a rough idea of how you can visualize what AddContact method is doing as it goes from top to bottom.

 

Wrap-Up

I am sure you are wondering why there is a GUID and what is a GUID. First, a GUID is a unique identifier that is created and there is never ever another guid with the same numbers and letters in the exact same order. This is useful to be able to uniquely identify data that there might be repeated information of the same type. So in the case of this xml file we could have a lot of contacts, but what if we wanted to delete a contact? We could delete by name, but what if you have multiple conacts with the same name? or even mulitple contact records of the same name, but differen information and you don't want to delete one of the multiple records. In that case we use the guid to find and delete that record.

I said I would post up the code for to the contact class so here it is.

I just want to re-iterate I am not an expert and need help myself on things. The above is a basic way of doing things to get you started. Please if you know of better way of doing things please feel free to leave a comment with your suggestion and advice. I do this to help others and to learn myself. Thank you for reading and please comeback for part two, retrieving data. In the meantime I am including all my code at the bottom of the post for you to play with it. It is just the cs and xml files. No project files.

XmlAccess.zip (2.22 kb)

This is in response to these two blog posts and the constant reference to the 20% and 80% I hear.
Version Control and the "80%"
The Two Types of Programmers

While generalizations are fine sometimes you can get too general. I do like where the 80/20 comes from and the overall vagueness behind it. However, there seems to be a couple of problems.

• There are some people who want to be 20%, but don't have the time to manage it other than at work.
• Part of the 20% is only learning and can't be pushers and innovaters.
• Those that enjoy development, but don't care enough about being better to be a 20%

The above people do exist and in the chart 10% area is where they sit. So this is where I disagree with Jeff Atwood (coding horror).

As I work with teams of programmers in the field, I'm consistently struck by the yawning abyss between that 20% and the rest of the world. It makes the divide between the open-source and Microsoft camps look like a shallow ditch.

While there may be a big divide there are those in between that do bridge the gap. So I honestly think the numbers should be restructured a bit to allow for this maybe a 75% 10% and 15% with the 10% in the middle like below.

The biggest reason I have a problem with two distict groups that are defined by Ben Collins-Sussman

The 20% folks are what many would call "alpha" programmers — the leaders, trailblazers, trendsetters

The 80% folks make up the bulk of the software development industry. They're not stupid; they're merely vocational.

That totally leaves out enthusiastic beginners and some of my friends and colleuges that want to be the above 20%, but really don't fit in the 80% either. So I guess that means the definitions need to be either further refined or the numbers need to be slightly altered.

What are your thoughts? Am I wrong?

For those that have visited the site in the last few days or are subscribed and wondering about updates.  I just want to let you know they are coming.  I am a college student and finals crept up on me and are next week.  I have 2 finals I am really studying for so that has taken a lot of time away from the blog, but my last final is on thursday so look for content by friday at the latest.  I am wanting to take some time and write a couple of quick posts before then.

Please hang around i'm not gone.

Part 1: TDD Test Driven Development for Beginners pt1
Part 2: TDD for Beginners pt2 - Pig Latin
Part 3: TDD for Beginners pt3 - The Application
Part 4: TDD for Beginners pt4 - Unit Tests

I like to do "Real World Coding" and "Real World Contexts" when doing tutorials, if I can. Someone suggested that most people that want to learn and do TDD usually want to start using it with an existing project, and I should go about the series in that way. I liked that idea, but it presented a simple problem of teaching the very basics of TDD. My solution is this part 2. I am going to walk you through doing a _VERY_ basic Pig Latin converter, and how to use TDD to accomplish writing it. Then the rest of the series is going to be how to incorporate tests into an existing project, and a couple parts on adding new features using TDD.

Download NUnit
Before you can do TDD you need to get something to run your tests. I personally use NUnit, but there are other options available.
Download ( Get the MSI for the latest version using .NET 2.0 Library )
Documentation

Next you need to Install it just run the installer. Just go through the normal next next next process.

How to configure Visual Studio to do Tests
This is pretty straight forward process and is a project by project basis. When you install NUnit it will add several NUnit assemblies to the GAC and when you start a new project that you are going to write tests for (which should be most now), you need to add new refernce, in the solution explorer, and choose NUnit.Framework assembly. Next you add the following line to your using statements.

using NUnit.Framework;

Once that is done you are pretty much set and ready to start writing tests.

Test Driven Development

Now that we have the preliminary stuff out of the way we can start to concentrate on what is important. Learning Test Driven Development. Sorry for the long post you are about to endure.

What we are going to write is a Converter class that allows us to convert words to another language. In the case of our example we are going write a class to be able to convert words to pig-latin (as long as the word doesn't start witha vowel). By writing it as a convter class it will make the code easier to use, implement, test, and extend.

TDD Process
There is a basic process you run through when doing Test Driven Development. I wrote about it in another post, but will re-list it here as it is very important and is the core to TDD.

1. Write the Test Code
2. Compile the Test Code (It should fail since you haven't implemented anything yet)
3. Implement Just enough code to Compile
4. Run the Test to see it fail
5. Implement just enough to make it pass
6. Run test to see it pass
7. Refactor for clarity and eliminate duplication
8. Rince and Repeat (repeat from the top)

I am going to walk you through each of these steps and explain them as I go.

Write the Test Code

First we need to create our test class file. So add a class file to a new console project (if you want following along) and name it ConverterFixture. The name means that this is a test file that will be testing the converter class.

The above code is what we refer to as writing the test code first. Lets walk through each line.

[TestFixture]

This is the attribute we set in C# to let NUnit know this class containts tests. It is a Nike thing "Just do it" at the top of your test classes. The class also must be public for NUnit to find and use it.

public class ConvertFixture

This is the name of the class that is going to containt all of our tests for our Converter class.

[Test]

This is the attribute we set in C# to tell NUnit this is an actual test that will be run. All the code in this method below is used to ultimately run a test.

public void ShouldConvertWordToPiglatin()

In order for the method to be a test it needs to be public, void, non-static, and take no parameters. Our method meets all those requirements. The naming might seem odd, but the purpose is so that you can easily understand the purpose of what "should" happen by the end of this test (Look up Behavior Driven Development). This may be obvious by our method test, but when you get into more complex code then tests can become exponentially longer with the purpose being lost. Though nameing is up to you this is what I do.

Converter c = new Converter();

Creates a new instance of the Converter object.

string word = c.ToPigLatin("hello");

From this code we are converting a word "hello" to pig latin using the instance of the converter object from above and assigning to a string object. Or we are converting hello to pig latin.

Assert.AreEqual("ellohay", word);

This is the bread and butter, kind of, of tests. Assertions are how you actually test things in TDD and using Assert object is how you do it in NUnit. There are actually quite a few Assertions you can make, but the one we have here is Assert.AreEqual which compares what the output "Should be" to what it actually is. I suggest when you get this far take a look through intellisense at all that are available to you to use.

Now what we have is a test for our converter object that we haven't made yet.

Compile the Test Code

If you are following along and doing TDD the correct way when you hit compile you will get a big fat ERROR and it won't compile. Congrats that is exactly what it is supposed to do. If it does compile something is wrong.

Implement Just enough code to Compile

At this point we are ready to start writing code for our program. We will write just enough code for our program to compile. The reason behind this is so that you don't write unecessary code and the more code you try to write to pre-implement/pre-solve problems can lead to problems later. Writing just enough code to compile can keep you in check so that you don't write too much code. Here is the code that is just enough to compile the program.

- In this code you can see we created the class Converter.
- Created a method called ToPigLatin() with a return type of string and takes a string parameter.
- It then returns the string s.

Now try to compile. It should compile with 0 errors.

Run the Test to see it fail

Next is to actually run the test. To do that here are the steps I follow from finding and opening NUnit to hitting run. Once you open the assembly in NUnit all you need to do is just hit run from then on after each compile.

1. Start
2. All Programs
3. NUnit 2.4.3
4. Click NUnit GUI (.NET 2.0)
5. File
6. Open Project...
7. Find assembly (which was in below folder)



8. Select Assembly
9. Click Open
10. Click Run

At this point it the test should fail

 

Implement just enough to make it pass

No we are ready to add the functionality to make that stinking test pass so we can feel good about our code working.

The code above is the code needed to make the test pass. I will run through the code mostly line by line after the declaration of the method.

char[] theArray = s.ToCharArray

Here we are taking the string and spliting up each individual character into an array to so we can manipulate it better.

string final = "";

We are setting the variable final to a nothieng string because are going to run through a loop and add characters to it.

the whole for loop

This is basically going through the array for the word and starting at the second character and assigning it to the variable final. So basically it is taking "hello" and turning it into "ello".

return final + theArray[0] + "ay";

Here we are taking ello adding h to the end and then appending "ay" to it. The final looks like ellohay. We then take that and return it so the test can check if it was done right.

Run test to see it pass

Now you should be able to hit the bug run button in NUnit once you compile the program and get everything all Green.

Feels good doesn't it.

Refactor for clarity and eliminate duplication

In this case we really don't have anything that we need to refactor so we can do the next step.

 
Rince and Repeat (repeat from the top)

If we had more to do then we start over from the top on the next method/functionality that we want to write. Remember though not to write to much functionality at once.

 

Wrap-up

Now that we have gone through all the steps i'll post up the final code and the code that implements the converter class we just wrote. Then the application that runs it.

ConverterFixture.cs

Converter.cs 

Implementation inside the main method

Program.cs

It actually running

 

Final Thoughts

As you can see Test Driven Development can be very effective in making sure that your code does work. What is great about TDD is that you can spend a while coding on a project and because you have tests later when you do some refactoring to make things prettier and work better you know if and where EVERYTHING is broken. Also TDD allows you to start almost anywhere in your application that you want so if you want to start in the business logic layer, lets say, and not in your data access layer you can because there are ways to test without haveing the Data Access Layer implemented, I will show that too later.

There are a lot of benefits and I can only talk about a couple of the benefits right now so as the series progresses I'll talk about more. In the next part, maybe couple of parts , of the series i'll post up the code for our application that doesn't have tests and do a walk through of all the code.

Please, feel free to download the code I have attached play with it maybe add your own language converter to it with some tests. Please give me any feedback you want good bad or indifferent.  

TDDSeries1PigLatin.zip (7.81 kb)