NetTiers Code Generation Cycle

Code generation is the biggest disadvantage to running an application on NetTiers.  The code generation cycle is a bit long and unnecessarily complicated.  It would be much easier to generate the framework code when the database updates via a simple one click apparatus (or a few word command) as done with Rails.**

Each time the database model updates, you must re-generate the framework for your application.  NetTiers provides a strong types/objects from tables in your database, so when your database changes, the code will change as well.  Running through five or six clicks and generating code guaranteed to work is much better than hand coding changes to three or four individual layers (unless you are billing a client and bill by how many keys you press per hour).

These instructions apply after you have setup your initial project.  [This will be a separate post … someday.  Email jasonhoekstra@gmail.com and send a letter of encouragement.]

0.)  You must have CodeSmith 4.0 or higher installed.  (I’m using 4.1 for this post.)
1.)  Open NetTiers.Cst (mine is located in C:\NetTiers_2.2\NetTiers.Cst).  Double clicking on a .cst file will open the CodeSmith engine.  (I drop an icon on my Quick Launch bar that shortcuts to NetTiers.cst.)
2.)  Open the configuration file for the project.  TJ, for BuddyBetter, I open C:\Projects\WCF\Products\BuddyBetter\BuddyBetter.csp.
3.)  Make sure that Visual Studio has closed the solution, otherwise, you’ll have to answer to five or six new project notifications.
4.)  Hit the Generate button.
5.)  A web page summary will pop up.  Scroll to the error count.  Make sure it is zero.
6.)  Reload the project file in Visual Studio.  Go back to work with your changes.

Linq or NetTiers?

With the core work of our first foray into collaborative web development out of the way, Jason and I have begun to discuss our next project. With that, I’m taking the opportunity to take a step back and think about what things we might be able to do differently next time around (me contributing more is but one).

In our first project, BuddyBetter.com, Jason and I leaned heavily on NetTiers to do most of the heavy lifting for us. It didn’t take me long to become an instant convert to how NetTiers could totally change my life as a coder. It’s fast, simple to use, and generates your entire data access layer for you. So why would I consider changing?

Enter Linq. With the release of .NET 3.5 and Visual Studio 2008, Linq finally becomes an ‘official’ part of .NET. Standing for “Language interpreted Query”, Linq is a radical new approach to treating a database in an object oriented fashion. Instead of the old paradigm:

// create dataset from a DB table    DataSet oDataSet = ExecuteDataset(ConnectionString, CommandType.StoredProcedure, "StoredProc",sqlParams);
 // Code here to load this dataset into a custom collection (or handle natively)

Of course the beauty of .NetTiers is that it handles the above code for you. However, under the hood it’s still treating the database like what it is — a collection of rows and columns that represent some object in the real world.

Where Linq differs is that it allows you to skip this conversion step and jump immediately to handling your database like a collection of objects. Now we can do something like :

using System.Data.Linq; // be sure to add this. the System.Linq namespace is not sufficient for SQL to Linq  // Create a class for each table we want to access (or use a tool like SQL metal to automatically create the classes for us)  [Table (Name="Groups")]
    public class Groups
    {
        [Column(IsPrimaryKey = true)]
        public Guid ID;
        [Column]
        public string GroupName;
        [Column]
        public string GroupSiteUrl;
    }     // now we can access our table thusly:  // actually handles the main connection to the DB
DataContext oContext = new DataContext(sConnectionString);            

// getting our table "Groups" --> see Groups.cs in this project
Table<Groups> Groups = oContext.GetTable<Groups>();
// query-like language. you can do wheres, group bys, orders, etc
var q =
 	from c in Groups
	select c;

 // all of the rows
foreach (var group in q)
	{
         	string s = group.GroupName;
                string r = group.GroupSiteUrl;
                Guid g = group.ID;
        }

And that’s it. You are now accessing table data using Linq.

So with all of this being said, what do we do for our next project? Stick with .NetTiers? Or move on to Linq. My gut tells me to sit tight and use NetTiers for the next project or two while we hone our Linq skills. I still have a lot to learn. Your thoughts Jason?

NetTiers Recipe – ParameterBuilder

NetTiers provides a wonderful way of querying a SQL database with strong .NET types and a query simplified language.

For this example, I’m building our queued email sender. I have stored a bunch of emails in the database and it’s time to send them.

In SQL, this is the query I’m trying to achieve:

SELECT
EmailQueue.*
FROM
EmailQueue
WHERE
SentDateTime IS NULL AND
ErrorMessage IS NULL

With NetTiers, I’m going to use the strongly typed ParameterBuilder class, in this case, the generated EmailQueueQuery.

EmailQueueQuery query = new EmailQueueQuery();
query.AppendIsNotNull(EmailQueueColumn.SentDateTime);
query.AppendIsNotNull(EmailQueueColumn.ErrorMessage);
TList<EmailQueue> messages = DataRepository.EmailQueueProvider.Find(query);

foreach (EmailQueue message in messages)
{ // now I have a strong collection of EmailQueue object, send email messages }

There are hundreds of ways to solve this problem. I could use a SQL string or stored procedure and fill a DataReader. I could use a custom stored procedure, regenerate and obtain the same collection of objects. I prefer the method above and here’s why:

1.) Everything is strongly typed. When the model (database schema) changes, my code breaks quickly. When TJ changes the ErrorMessage to ErrorMessageType, regenerates and recompiles, there is going to be a big error message saying WCF.Entities.EmailQueue does not contain a definition for ‘ErrorMessage’. To me, breaking the code quickly (and repairing it quickly) is good. The alternative with the SQL text or stored procedure is to retest every reference to the query. (One of my favorite generated objects from NetTiers is the <T>Column enum, which contains the column names from the target table. No need to flip back to SQL Server to see what you called that field — IntelliSense will provide in Visual Studio!)

2.) I’m sure many DBAs would have my hide for this, but I prefer to keep everything in .NET and Visual Studio. Each time I have to leave the IDE, my attention is distracted. The parameterized query keeps my head down in the space of the problem. If we find during testing, the query is too slow and we need to refactor and replace, we can do that. For now, this is a simple solution which enables fast (as in keystokes, not always performance) database access. For me, it’s better to start simple and make complex as the situation dictates. I’ve found that parameterized queries fit around 90% of my data access needs.