Golf is a Patience game where players try to earn the lowest number of points (as in golf, the sport) over the course of nine deals (or “holes” to further use golfing teminology). It has a tableau of 35 face-up cards and a higher ratio of skill to luck than most other solitaire card games.

My attempts in this tutorial series will be able to keep the code reusable and hopefully build onto this series with other Card/Solitaire games.

XNA Tutorial Series 1: Golf (Patience) Solitaire Part III – Deck Class
For this tutorial we will focus on the class that will handle the logic for a group of cards. Start by right clicking on your classes folder and adding a new class called Deck.cs. The first thing we will need to do is setup are using’s as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;


Next set your class to be public.

Now we can begin by adding a Enum to our class to represent a deck type:

public enum DeckType
{
User = 1,
Source,
Waste,
Target
};


Now we can setup the individual properties that a Card will have, I will show the code first and then proceed to explain what each property is for:

protected List cards = new List();
protected Point pos;
protected int deckID;
protected DeckType deckType;
Texture2D background;

public DeckType Type
{
get
{
return deckType;
}
}

cards will be a list of the cards in the deck, pos is a point that is used for offsetting a card image so you can have one card on top of another and see the values for both. deckID is an ID for keeping track of the decks. DeckType to indicate the enum for which type of deck it is, and a texture to store the decks background.

Next we have our constructors:

public Deck()
{
deckType = DeckType.User;
}

public Deck(int id)
{
deckID = id;
deckType = DeckType.User;
}


Since this deck class is going to be a base type it will default to being a user deck, other deck types (waste, source, etc..) will implement the desk class. Next we will need some basic methods for maintaining the list of cards that are in the deck.

First we will need to be able to retrieve the number of cards in the deck:

public virtual int CardCount()
{
return cards.Count();
}

And finally get a card
public virtual Card GetCard(int index)
{
return cards[index];
}


In the second part of the deck class we will look at Adding cards, handling input, and drawing the cards.

In order to get away from code being escalated to MSDTC (Microsoft Distributed Transaction Coordinator), I decided to use single SqlConnection per TransactionScope.  Also, to maximize code reusability, we ended up with the following development pattern.  For simplicity reason, error handling is not added in the example below.

public static void CreateOrder(Order myOrder)
{
    using (TransactionScope scope =
            new TransactionScope(TransactionScopeOption.RequiresNew))
    {
        using (SqlConnection cn = DB.GetConnection())
        {
            cn.Open();
            SqlCommand cmd = new SqlCommand();
            cmd.Connection = cn;

            InsertOrderTransaction(myOrder, cmd);
        }
        scope.Complete();
    }
}

internal static void InsertOrderTransaction(Order myOrder, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrder";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@CustomerID", myOrder.CustomerID);
    // ...

    myOrder.ID = Convert.ToInt64(cmd.ExecuteScalar());

    InsertOrderTransactionPostProcessing(myOrder, cmd);
}

As you can see, the method InsertOrderTransaction takes the Order object and a SqlCommand instance. It assumes that the SqlConnection has been established for the SqlCommand in the calling method. It doesn’t care if the SqlCommand needs to be executed within a transaction or not. It simply executes a SQL statement or a Stored Procedure. In its calling method CreateOrder, it defines the TransactionScope and defines and opens a SqlConnection. It can call multiple transactional methods (in this case InsertTransaction) and keep them all in one transaction. However, you don’t have to define a TranscationScope in the calling method if you are not dealing with multiple SQL operations. You can also add pre-processing and post-processing functions if needed.

internal static void InsertOrderTransactionPostProcessing(Order myOrder, SqlCommand cmd)
{
    if (myOrder.OrderItems != null)
    {
        foreach (OrderItem myItem in myOrder.OrderItems)
        {
            myItem.OrderID = myOrder.ID;
            InsertOrderItemTransaction(myItem, cmd);
        }
    }
}

internal static void InsertOrderItemTransaction(OrderItem myItem, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrderItem";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@ItemID", myItem.ItemID);
    // ...
    myItem.OrderItemID = Convert.ToInt64(cmd.ExecuteScalar());
}

One thing you have to be aware of is that TransactionScope may not be a good choice if these operations take too long to complete. The reason is obvious. Transaction may result in temporary locking on certain objects (such as tables) in your database. If the transaction needs 5 minutes to complete, it may lock a table for that long and your users may be unable to access data in the table for that long. If anything goes wrong at the very last second in the transaction, it may take another 5 minutes for the database to roll back previous operations in this transaction, and make the table inaccessible to your users for even longer. So in cases like this, one transaction may need to be broken into multiple segments.