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.

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.