The name is self-explanatory; however, it's worth mentioning that the purpose of this metric should be only to get a clue of the complexity of the code, and must not be used to measure progress. Clearly, a method with five lines of code that calls other methods will be simpler than if you inline all 25 lines of code in that method.

public class OrdersGenerator
{
  public void GenerateOrder(Order order)
  {
    IsUnderCreditLimit(order);
    IsCustomerBlocked(order.Customer);
    AreProductsInStock(order);
    IsCustomerBlocked(order);
    SaveOrder(order);
  }
  // remaining methods are omitted.
}

If you compare a class with six methods, as shown in the preceding code, with a class having the same functionality, but with all the code inlined in one method, the latter will have 25 lines. Assuming the remaining methods have five lines each, the former will be 30 lines long, although it is simpler. You have to be careful about how to consider this metric; a longer class might be better than a short one.

This metric counts the base classes; some recommendations are to have a value lower than six. But this, like other metrics, has to be looked at with special care. It's hard to give a recommended value and it's relative to which classes you are inheriting from. If you inherit from LinkLabel, you will have a depth of 4, but your base classes are less likely to change than if you inherit from ProviderXComponent and have a depth of 1. It's more probable that ProviderX will change his component and break yours, while Microsoft will take more care not to break code. But you'll probably never update ProviderX's library. The point is that this metric is relative to what base classes you have.

This counts the dependencies an item has on other types except for primitives and built-in types like Int32, Object, and String. The more dependencies you have, the harder it's supposed to be to maintain, because it would be more probable that changes on other types will cause a break in your code. Similarly to depth of inheritance, the importance you give is relative to the dependencies you have. A class referencing System libraries is less likely to have a break than classes referencing other types on active development. You can see a value for this metric at each level of the hierarchy (project, namespace, type, and member).

Cyclomatic Complexity is a measure of how many paths of execution there are through your code. A method with higher cyclomatic complexity is going to be harder to understand and maintain than one with a lower value. It is hard to find a recommended value for this metric because it depends on the level of your team and on the team that will maintain the product. Far more important is trending information — a steadily increasing cyclomatic complexity indicates that your code is getting harder to understand and follow. Having said that, sometimes a complex solution is warranted.

This metric is calculated using a formula that considers cyclomatic complexity, lines of code, and the Halstead volume, which is a metric that considers the total and distinct number of operators and operands. It will give you a range between 0 and 100, with the higher being easier to maintain than the lower.

Code marked with the CompilerGenerated and GeneratedCode attributes won't be considered in the metrics. Datasets and Web Service Proxies are examples of code marked with the GeneratedCode attribute, but other generated code (like Windows Forms) isn't marked and will be considered in the metric's results.

To configure your session, simply right-click and select Properties. In the General section you can change between Sampling, Instrumentation, and Concurrency (Figure 55-4), and choose if you want to activate .NET memory profiling collection, the output for the reports, and the report names.

Figure 55-4. Figure 55-4

In the Sampling section, you can select when to take samples; by default this is set to 10,000,000 clock cycles. Depending on what you want to track, you can change the sample event to page faults, system calls, or a particular performance counter.

Enabling Tier Interaction Profiling (TIP) allows you collect information about synchronous ADO.NET calls between your application and SQL Server. This includes the number of times each query is made and how long each one took. If you are profiling an ASP.NET WebForms application, TIP is also able to provide data about page request counts and generation times.

The Instrumentation section is used to specify pre- and post-instrument events, for example signing an assembly with a strong name. These settings are set on a per-target basis. The last section in the property page, Advanced, is also used when instrumentation is selected, and there you can specify additional command arguments. To see a list of available options, search for VSInstr on MSDN. VSInstr is the tool used to instrument binaries.

The remaining sections are used to specify the collection of different counters or events. CPU Counters will let you capture additional low-level information and will be displayed as extra columns in the different report views. These are only available for instrumentation. The Windows Counters are system performance counters and you will be able to see the results in the Marks report view.

The Windows Events section will let you specify event trace providers. To see the information on Windows events, you would need to manually get a text report using the following command:

Vsperfreport c:<path>ReportName.vsp /calltrace /output:c:<path>

Once you are all set, you can start the application, test, or web site from the Performance Explorer. It will run as usual, but will be collecting data. Once your application terminates, a report will be generated. Table 55-1 shows a description of some of the report views and Figure 55-5 shows the Summary View.

Additional reports can be generated using the command-line tool VSPerfReport. For more information, consult the MSDN documentation.

Allocation and Object Lifetime are only available if you select Collect .NET Object Allocation Information and Also Collect .NET Object Lifetime Information, respectively, in the session's property page. Some of the report views are different depending on the configuration. To see a description of a particular column, simply hover over its title. You should go through the documentation on MSDN to get a thorough description on each report.

Figure 55-5. Figure 55-5

In all the views, you can use the filter from the toolbar to get to specific information. You can add or remove columns by right-clicking a header and sort using a particular column. Reports can be exported to either XML or CSV and successive reports can be compared against one another, allowing you to spot changes in your application's performance.

In the New Project dialog inside the Database node are two nodes for C# and VB SQL-CLR Database projects. These are used to create managed classes to use inside a SQL Server. When you create a new project of this type, you will be prompted for a connection and to enable CLR debugging. Use CLR debugging only on development database servers and isolated from other developers, as explained later in the "Best Practices" section.

You can add to this project some types like Aggregates, User-Defined Functions, Stored Procedures, Triggers, User-Defined Types, and Classes. You can think of this as a normal VB/C# project; you can add classes, references, and even web references. You can create unit tests for your methods as explained in Chapter 11, refactor your code, and build, in the same way you would for other library projects. However, the debugging history is a bit different, because your code is running in an SQL Server context. First you will need to allow VS to remote debug the code. This is needed only the first time you debug your project. However, the point of entry for your code will be through a script that will use any of your managed objects. As you may have noticed when you created the project, there's already a file named Test.sql, which is used to create and test your types.

The test scripts can grow quickly, and long script files are not easy to maintain. You can add new test scripts and right-click to set them as Default Debug Script. This is similar to the way you would set an ASP.NET page as the start page. You can set a breakpoint on the script or the classes you are testing and hit F5 (or from the menu Debug

There's another type of Database Project and it's inside the Microsoft SQL Server node, as shown in Figure 55-9. As you can see, there are three options each for SQL Server 2005 and SQL Server 2008, but it's basically the same project type; the difference between them is the use of a wizard and the SQL Server version being targeted. Some options are available only from the creation of the project using the wizard, so I suggest you start using that. These projects will let you have an offline representation of your DB schema, so that you can version it along with your code. It will create a file for each schema object and deploy the changes to a database.

Figure 55-9. Figure 55-9

If you run the wizard for SQL Server 2008, the first option will let you choose whether your project will manage a single database or a SQL Server. This is the same as choosing either Database Project or Server Project in Figure 55-9. The other option on this page is to organize the files by schema or object type (tables, views, stored procedures, and so on). This is important because you can't change this option once the project is created, although you will find yourself working on the Schema View most of the time instead of doing it directly on the files — from that window you can select or deselect the filter by Schema View. However, if you select "No" to organizing by schema inside the types, you can still distinguish the schema because of the prefix added to each filename. On the other hand, if you select to organize by schema, inside of each you will have folders for each type. Figure 55-10 shows at the left the Schema View filtered by schema. You could change this option to organize all the objects by type. The Solution Explorer (at the right) shows two different projects where files are physically organized differently.

Figure 55-10. Figure 55-10

The database options are the next step of the wizard; if you don't know your defaults now, don't be afraid to choose something and change it once you get this information from either your DBA or your production DB. You can select to import this configuration directly from a DB. If you can connect to your production DB, it's a good idea to import them at this moment. To do this, simply go to the next step in the wizard and mark the needed checkboxes as shown in Figure 55-11.

The last step is to configure the build and deployment options. You will need more deployment configurations, so here you will only select your development database. Keep in mind this doesn't have to be the same as in the previous step — here you are configuring your development database and in the previous step, if available, you would import existing objects and configuration from a production DB. You see the three configurations needed in more detail later, so for now you can go with the default options. The final step will take a while, especially if you have many objects to import.

Figure 55-11. Figure 55-11

Once the wizard finishes, you can add, edit, or delete schema objects right from the Solution Explorer or the Schema View (View

When working with Source Control, this type of project becomes really useful. The scenario would be that each developer works on his own server instance. One of them has made changes to the schema and his .NET code and deployed them to his instance. He then tests the .NET application and it works fine with the new database changes. Then he checks in all of his changes to the server and another developer retrieves the changes. When the second developer deploys his database instance it is also updated with the latest changes, and he will be running the new code changes along with the new schema changes applied to his SQL Server instance.

In addition to versioning the schema, you might want a way to generate data for testing purposes. To do this, you need to add a Data Generation Plan. If you right-click the Offline Schema project under the Add menu, you will find the option for Data Generation Plan. By default, all the tables on the schema will be selected, but you can override these settings. In the top section of Figure 55-12, only the Products table is checked. The ProductModel and ProductCategory tables are automatically added (darkened checkboxes) because of the foreign key between Products and those tables.

Figure 55-12. Figure 55-12

In the plan, you can select the ratio between Related Columns; for example, in Figure 55-12 we are specifying to have 10 products for each subcategory (10:1).

In the Column Details window, all columns are selected except for the ProductID, which is an identity column. You can deselect columns as long as they have either a Default value or allow nulls. In the properties window you can specify the percentage of nulls to be generated.

For each column, you can also specify the type of generator to use. By default a generator will be selected depending on the data type, or in case a column is a foreign key, the values will come from the related table's primary keys. You can use other generators. In the example in Figure 55-12, for the Name on the Products table we used a regular expression to mix first names and last names. Another option would be to use a Data Bound Generator. In that case, you would need to specify a connection string and a select query to get the values to insert. You could also create a Custom Generator and implement your own logic simply by implementing a base class and registering your assembly as a Customer Generator. For more information see "Creating Custom Generators" on MSDN.

To run the Data Generation Plan, simply select Generate Data from the Data

Chapter 8 introduced the topic of refactoring for normal .NET code. For databases you have only three refactoring tasks: Rename, Move Schema, and Fully-Qualify Names. You can rename tables, columns, stored procedures, constraints, and indexes, as well as other database objects. You can also rename the references to other servers or databases if a cross-database reference is used in the scripts.

To rename an object from the Schema View, right-click it and select Rename from the Refactor submenu. When renaming an object, you will see a preview of the changes as shown in Figure 55-13. In the upper pane you will see the old version, and in the lower pane you will see the new one for all the dependencies.

Figure 55-13. Figure 55-13

Renaming is easily done on an offline schema version, but for tables and columns it can be hard to deploy to the database. Because the old object will be dropped and re-created, this can result in data loss. If you have a Data Generation Plan, you can regenerate the data after the changes are deployed, but if you need to preserve your data you should either modify the deployment script or apply the refactoring manually. See "Protecting Data during a Renaming Operation" on MSDN for more information.

This tool enables you to compare schemas between databases or Database Projects. To use it, select New Comparison from the Data

Figure 55-14. Figure 55-14

For each DB object, you can see the action that will be applied. Then from the toolbar you can either select Write Updates to apply all the changes or Export to Editor to get the SQL statements used for the update in case you need to do manual changes or hand it out to your DBA.

To customize the options for Schema Comparisons, go to Tools

Remember that if you are using a Database Project, the deploy option will write the changes from your Database Project to the database selected in the build option in the project's properties. This tool can be useful to see the changes or do manual tweaking.

This tool is useful for copying data from one database to another. Go to Data

You will be presented with all the objects selected in the last step of the wizard, but only the objects with differences will be selected. I recommend filtering the view to show only the Selected Records. From there you can check/uncheck the changes you want to apply either at a table or row level.

Figure 55-15 shows the comparison results between two versions of a simple Products database. The upper pane shows the tables and the lower pane shows the records for the selected table. The Different Records tab in the lower pane will show side by side each Source and Target column, so you can see where the differences are.

Figure 55-15. Figure 55-15

From the toolbar you can select either Write Updates or Export to Editor to manually apply the changes.

Visual Studio 2010 Premium and Ultimate include static analysis tools for databases as well as for code. To run the static analysis tools, select Data

This editor allows you to work with Transact-SQL (T-SQL) code directly in Visual Studio. To open it, you can double-click a .sql file in Solution Explorer or from the Schema View of a Database Project. Another option is to start with a blank editor — to do this go to Data

The following is a list of best practices we compiled through our work with Database Professionals and which have worked for us on small and medium-sized projects: