Kevin S. Goff: Stages of Data

10/05 tip: Interfaces (Part 1 of 3)

Over the next 2 months, I'm presenting a session in the .NET community on interfaces.   A popular INETA speaker has told people that they don't need to know about interfaces.  While interfaces take time to learn and sometimes confuse developers, I strongly disagree with this advice. 

A common definition/description of an interface is a contract that guarantees how a class will behave, and what properties and methods the class will contain.  When you create an instance of a class that implements the interface, you can be assured that the class will contain  every PEM that the interface defined.  Think of the interface as the bullet point list of what will be in the class.

When I first read definitions like that, my initial reaction was, "OK....so what?  How can that help me?"  Quite a bit, as we're about to see over the next few nights.   

I'm going to post three samples from the Common Ground Framework that I discussed in the July/August '05 issue of CoDe Magazine.   For over a year, interfaces were an area of study and focus for me.  In addition to all the textbook benefits of interfaces, they also carry some other practical benefits:

• They can reduce the need for reflection
• They help to get around the issue of multiple inheritance in C#
• They're valuable in distributed application development using remoting

The three examples that I'll cover are "real-world" situations:

• Many applications utilize data binding.  Controls are bound differently (e.g. the code to bind a textbox is different from a checkbox, different than a combobox, etc.).  The Common Ground Framework contains a data binding interface that not only reduces the amount of code to be written, but also abstracts the binding behavior to reusable classes that implement the binding interface.
  
  
• You're building a client Winform application that needs to communicate with a set of business objects.  The Winform project/solution doesn't contain the business object DLLs, because they reside on the server.  So you need to call methods in business objects that don't exist on the client domain.   When you're using web services, you have the benefit of the web service proxy, which exposes the methods in the web service.  However, in a remoting situation, we need to define our own "proxy". 
  
  The Common Ground Framework includes an example of interfaces and remoting that allow a developer to create an instance of a remote business object, cast it to an interface that defines the PEMs for the business object, and "discover" the PEMs through intellisense.
  
  
• Many business applications have several "data maintenance" forms that allow the user to perform basic tasks:  retrieving records that match a certain criteria, browsing/navigating through the results, editing records, adding records, etc.    The tasks are usually common, though the lookup criteria and data for each form is very different.  The Common Ground Framework contains a base form maintenance class and a series of interfaces to simplify the creation of data maintenance forms in such a way that the forms will have a consistent look and feel.

Stay tuned for Part 2, where we dive into the details!

Peace out...KG

 

10/04 tip: Creating a DataTable from a DataView

Yesterday I wrote that Crystal Reports doesn't recognize a dataview as a datasource.  Developers looking to report against dataviews in Crystal must convert the view to a datatable.  You can do this in VS2005 through the new DataView.ToTable method.  A basic functional equivalent in VS2003 is as follows:

public DataTable ViewToTable(DataView dv)
{
            // Create a new table structure from the table object of the view
            // then loop through the view and import the rows into the new table

            DataTable DtReturn = dv.Table.Clone(); 
            foreach(DataRowView drv in dv)      
                   DtReturn.ImportRow( drv.Row);

            return DtReturn;
}

You can plug that into a generic library and use it to create a datatable from a dataview.

On Wednesday thru Friday, I'll cover practical uses of interfaces in the Common Ground Framework for .NET

Peace out...KG

10/03 tip: Reporting against dataviews in Crystal

I've built (literally) hundreds of reports using different versions of Crystal Reports.  You can produce great output with it, which makes users happy.  However, Crystal also has quirks, which can frustrate developers.    Fortunately, some can be resolved.

For example, suppose you've created an ADO.NET DataView (e.g. AmountOwed > 5000), and you want to generate a report based on the contents of the dataview.  So you instantiate the report object, and issue the following:

oMyReport.Database.Tables[0].SetDataSource(MyDataView);

It compiles and runs without error - but the report output is blank! As recently as CR10, Crystal doesn't handle dataviews the way you'd expect. Business Objects confirms this as a known issue, and suggests that you populate a new DataTable object with the filtered data and pass that table object to the report.

I haven't tested brand new CR11 yet to see if it supports DataViews.  Even if it does, there are probably thousands of developers who have to stay with prior versions of CR.

In VS2005, converting a dataview to a datatable is easy - you can take advantage of the new DataView.ToTable method.  However, those using VS2003 must write some code.  I'll be back tomorrow with a little bit of code to handle that in 2003.

Peace out...KG

Weekly commentary: Weighing in on Typed Datasets

I’ve had some recent discussion with developers about typed datasets. I use them regularly. Here are the benefits I’ve enjoyed from them (no order of importance):

• Typed datasets give you the ability to use IntelliSense for statement completion, and type checking at compile time.   They also make it easy to define default column values when you add new datarows.
  
  You can also read a column value directly without needing to write a conversion (int Qty = MyDataRow.MyQty, instead of int Qty = Convert.ToInt32( myDataRow["MyQty"]). 

• If a typed dataset contains table relations, the XML schema definition tool adds methods to the typed dataset class for traversing hierarchical data.  For example, a developer can write parent/child code for the tables DtOrderHeader and DtOrderDetail by using two methods that the .NET schema tool automatically generates: GetDtOrderDetailRows and GetDtOrderHeaderRow.  (A developer can use annotations to define alternate naming conventions: I'll cover this at the end).

• Additionally, if you define a primary key for any table in a typed dataset, the class exposes a Find method associated with the column name.   A developer can perform a FIND against a table with a primary key of OrderID by using the method FindByOrderID.  If the primary key is a concatenation of two columns (CustomerID and OrderID), the developer would use FindByCustomerIDOrderID. 
  
  In general, there’s less code to write because the typed dataset class contains generated code for building the schema and creating the necessary table, column, row, and relation objects.  The code you do have to write can be cleaner, more compact, and easier to maintain.

• Working with null values is a little easier when using Typed Datasets.  Each strongly-typed datarow contains a method to check if a column value is null…if MyRow.IsAddressNull().  The datarow also contains a second method to set a column value to null….MyRow.SetAddressNull().    Again, I'll cover annotations below, which also provide flexibility in dealing with nulls.

• Typed datasets serve as documentation for stored procedure result sets.  This benefit becomes even more important on multi-developer projects.   You can also define typed datasets as a separate project/DLL and then set references to them from the projects that use them.

• Typed datasets are valuable in the reporting process.   A developer can design report content from a typed dataset definition, even before the stored procedures are constructed.  Once again, the typed DS becomes a form of documentation for the report datasource.  I’ve developed hundreds of reports using different data access methodologies, and find typed datasets to be the most efficient.

• You can subclass a typed dataset class to add validation code or any other methods for the dataset.

• Typed datasets can simply design-time data binding – a developer can define a data source in the property sheet.    Developers who define data sources in code still gain the advantage of table/column name discovery through Intellisense.
  
  Typed datasets aren’t perfect.  They carry overhead.  While certain specific aspects of typed datasets are faster than untyped datasets, instantiating a complex typed dataset can be costly.  An application that frequently creates an instance of the same typed dataset will spent a measure percentage of time on the creation process.  Uri N. has developed a proxy class for typed datasets so that the actual creation only needs to occur once.   You can find his class on the CodeProject.
  
  Another complaint about typed datasets is the default naming conventions in the Typed dataset class for items like the DataTable/DataRow objects and methods/events.   The generated names may not be consistent with the preferred naming conventions on your development projects. Fortunately, developers can use Typed Dataset Annotations to solve some of the common naming issues, by allowing developers to modify the names of elements in the typed Dataset without modifying the actual schema. 
  
  Annotations also allow you to specify a nullValue annotation to instruct the typed dataset class how to react when a column is DbNull.  You can optionally tell the typed dataset to return an empty string or a default replacement value.  Shawn Wildermuth demonstrates typed dataset annotations in this excellent online article.  
  
  Another common criticism of typed datasets is that developers must update them anytime a stored procedure changes.  That is true.   (And in reality, if you add a column or table to a result set, the new data will appear in the dataset: it just won’t be strongly typed).  However, if new columns or tables are added to a stored procedure, chances are good that other components of the application will be modified as well to reflect the new data (screens, reports, validations, etc.)
  
  I work heavily with stored procedures, complex result sets, data views, and business/financial reporting, so typed datasets are an important ingredient for me in development methodology and producing results.
  
  I give credit to Bonnie Berent for helping me understand the value of typed datasets.  I used them immediately when I started working with Crystal Reports .NET, but she's helped me over the years to understand and take advantage of the other benefits they provide.  Bonnie answers many .NET questions on on-line forums like The Universal Thread, GotDotNet, as well as other Microsoft Newsgroup forums.
  
  Coming this week:  some Crystal tidbits, and a discussion of functionality in the Common Ground Framework.  Stay tuned!
  
  Jazz recommendation for the day: Personal Appearances by Sonny Stitt.  A must-have for bop lovers.
  
  Peace out...KG