Archive for November 2007

Visual Studio 2008 FxCop Errors

I converted a 2005 solution over to 2008 and hit build. I received this error:

MSBUILD : error : Invalid settings passed to CodeAnalysis task

I figured out that the problem was Visual Studio was calling FxCop from the "Visual Studio 8" directory instead of "Visual Studio 9.0". To fix this I had to change an environment variable called "FXCOPDIR" to point to the 2008 instance of Visual Studio.

I’m not sure why the install of 2008 didn’t do this. Oh well.

DevConnections – Make WPF Data Binding Work Against Business Objects

This talk was given by Rockford (Rocky) Lhotka.

Rocky works for Magenic and is kind of a home town hero around here. People are always talking about him and his books and his CSLA Framework and etc, but I’ve never seem him speak before, so I was looking forward to this.

Rocky talked about how data binding works with WPF and gave some examples. The real meat of the talk was centered around the gotchas, and how to work around them. I’ll mention one of them here.

If you create custom objects and a custom data provider and bind that to WPF, you need to implement INotifyPropertyChange. This will cause the UI to refresh itself with the new data, when the data changes. There is a problem here though. When re-bind the data, WPF will check if the data has changed, if not, it won’t refresh the UI. WPF uses the .Equals method to do this, rather than comparing references. If you’re using a database, most of the time you’ll have the .Equals compare something like the Id of the record, and maybe a few other fields. If you update some data that isn’t a part of that, WPF will think it’s the same object and not re-bind. The way around this is to write an identity converter that doesn’t actually do any conversions. If a value from WPF runs through a converter, it will always update the UI afterwards.

Of course Rocky was pushing his CSLA Framework as a sort of a cure for all problems, but he did get into what he was doing in the framework, and why he had to do it. I’m personally not a big fan of the framework, but it was nice to hear the reasoning behind everything he’s doing. He’s definitely a smart man, and I have a lot of respect for him after hearing him speak.

WPF seems like a very powerful tool, but it will take some time for developers to get used to a new programming model like this. I think it has great potential, and is where most, if not all Windows development will be heading in the future.

DevConnections – Building a LINQ Based Business Layer for ASP.NET Apps

This talk was given by Rick Strahl.

This talk was very upsetting. There was a person asking entry level LINQ questions though out the whole thing… and yes this is the same person as in the other sessions. I don’t know how I ended up choosing the same ones as him. Rick kept answering his questions, and in the 1.5 hour session, got to the actual topic in the last 5 minutes. I was really disappointed, ’cause this was one session I was really looking forward to.

Basically, how this is done is you would create business objects and pass up a type that can be queried using LINQ. You can pass a type from the LINQ to SQL data context, limiting it to a specific object/table. This way a consumer can still run a LINQ query on the object, and the query will be optimized and not ran until needed, just like if you were using the data context directly. You can then create all the business rules you want around these objects.

One of these days I’ll write up some examples of how this would work and post them.

DevConnections – Implementing the Entity Framework

This talk was given by John Papa.

The Entity Framework, or LINQ to Entities, is a lot like LINQ to SQL. The difference is, it adds a mapping layer on top of it.

When creating a data layer using LINQ to SQL, objects are created that represent the SQL tables. The the SQL changes and you want your code to reflect those changes, you can refresh your code, but that may break a lot of things too. With LINQ to Entities, you have a mapping layer on top of the objects that represent the SQL. This way, you can map any object structure to the real structure.

The Entity Framework allows a conceptual model to use inheritance, merging of objects, splitting of objects, and complex types. There are 3 layers; the conceptual layer, the mapping layer, and the logical layer (LINQ to SQL is basically just the logical layer). There will be generation tools and wizards to create your objects with this rich ORM.

This talk was mostly examples, so I don’t have a lot to write about. The Entity Framework is definitely a better way to go than using LINQ to SQL. Hopefully it’ll be released in the near future.

XNA Game Studio 2.0 Beta Is Out

With all the hype of the Visual Studio 2008 RTM coming out yesterday, I completely  missed that XNA 2.0 Beta was released.

The most notable feature is that it will run on all versions of Visual Studio 2005 now. This is great because unit testing, code coverage, and many other features are now available. Hopefully they’ll have support for Visual Studio 2008 by release time.

The other big feature is networking support. Now you can create networked games that will work on the XBOX 360.

DevConnections – Inside Partial Rendering

This talk was given by Dino Esposito.

This talk was once again flooded with entry level questions from the same person who ruined a few other sessions I attended. Dino did a good job of answering them quickly, and trying to move on. This guy just wouldn’t shut up though…

Basically, there are 2 approaches to ASP.NET AJAX. You can use script services, which is the javascript library directly. Or you can use partial rendering, which is a set of new controls that handles all the guts for you.

Dino went into some detail about how the update panel works internally, but I had already got an in depth talk about it from Eilon Lipton, the person wrote wrote the update panel, in a previous session.

A couple interesting things I caught are; There are page lifecycle event methods, such as "function pageLoad()", just like in ASP.NET. There is an easy way to do getElementById on an ASP.NET control (which has a dynamic client id generated). You just use $get() instead.

DevConnections – MVP Pattern in Real World Enterprise Systems

This talk was given by Dino Esposito.

We currently have an implementation of MVC/MVP with ASP.NET on my team, and it’s completely different than the architecture Dino talked about. I always like seeing alternative ways of doing the same thing with architecture.

What is the difference between MVC and MVP?

The MVC pattern doesn’t define a clear architecture. It defines a relatively loose strategy for making 3 actors (model + view + controller) interact. It creates a separation of concerns.

The MVP pattern is MVC based on 3 facts:

  • The view doesn’t know about the model, but receives DTO’s (Data Transfer Objects).
  • The presenter ignores the technology behind the view.
  • The view is mock-able for testing purposes.

With MVC, the controller holds a reference to the model and the view. The View holds a reference to the model and fires events to the controller. The model fires events to the controller.

With MVP, the presenter holds a reference to the model and the view. The view fires events to the controller. The model doesn’t know about anything.

Dino went through a fairly thorough example of how you could architect this, and ran some actually code that did reads/writes to a database. Here is the gist of it… For each page or form, you create an interface, which is your view. The page/form implements the interface. When the page/form loads, the presenter is created and passes in the view interface, which is a instance of itself (this). The page/form then calls initialize on the presenter. This will do all the initial work. The presenter will set the IView properties, which directly sets the page/form controls values. For this to be mock-able, the properties on the IView use DTO’s. So, instead of exposing a drop down list, it would expose a generic object that would be connected to the drop down list on the page/form. When an event occurs, the event subscription method will call a method on the presenter, and the presenter will handle everything.

Personally, I like the idea of hooking the events of the page/form up directly to a method on the created presenter. Otherwise, the event subscriptions of the page/form are pointless. All it does is call a method on the presenter. Nothing else.

Overall, I really like this architecture. I really don’t know the different between MVC and MVP before this talk, and now it’s clear. I think I like the MVP approach better.

DevConnections – Dealing with Long Running Requests in ASP.NET

This talk was given by Rick Strahl.

What is considered a long running request? When it overruns the max thread pool, is CPU intensive and runs for more than a couple seconds, or it has a high user count.

There are 100 threads per CPU in the ASP.NET request pool. This works differently if you’re using IIS6 or IIS7. With IIS6, threads originate with ISAPI. Win32 native threads are fed into the ASP.NET engine, then released back to IIS. With IIS7, there is an integrated pipeline. IIS threads fire directly into the ASP.NET pipeline. There is no difference between an IIS and ASP.NET thread.

There are several scenarios (solutions) Rick talked about, to handle long requests.

Scenario 1: The app is busy interface.

This is basically a "fake it" solution. You do something silly like disable buttons and show a progress bar to people know there is something happening but have to sit and wait. You disable the interface so the user doesn’t click again. A new click will cancel the current request on the client and start a new one. The request on the server will keep running though, and take up resources.

Scenario 2: Async processing.

This works well for I/O bound processing, but not for CPU bound processing. ASP.NET (2.0+) has things build in to make this easy. You can use page async tasks, and async operation callbacks. This will return the thread to the pool while waiting. When the request comes back, it grab the thread from the pool, and continue. Basically your page will run it’s course while the async stuff is happening, but won’t be rendered until all async tasks have returned.

Personally, I think this is a nice way to do it. You can keep firing off new async events when another finishes, so if there is a request that takes some time during the async work, the other requests won’t be affected by it.

Scenario 3: Threads and delegates.

This works well in the run and forget scenarios. ASP.NET disconnects from the thread, and continues processing the page, including rendering the page. If there is a task that you don’t want to block your page from rending, and you don’t need any information back from it, such as logging or writing something to SQL, this is a great way to do it.

Scenario 4: Background scheduling.

You can queue your requests or have non ASP.NET threads do the work. He didn’t talk much about this option. It doesn’t seem like something that would be used all that often.

Scenario 5: Async messaging.

You can use message based communication. Store your message somewhere, like SQL, and check back to see if the task is completed. This would be used in conjunction with the "app is busy interface" method.

If you have a site that uses services, is CPU or I/O intensive, or is just slow, Rick had several good ways of possibly speeding up your application. There are other things to consider also. If you’re using SQL, make sure indexes are set correctly, queries are optimized, and if you’re db is hit hard, putting the db and the log on separate drives, or even going as far as writes and reads are in separate db’s.

If you want to know more about async pages in ASP.NET there is a good MSDN article on it.

Windows Live Goes Live! (RTM)

The Windows Live tools went RTM. I’m using Live Writer to post to my blog right now. The beta version of Messenger was horrible, so I hope they’ve fixed all the bugs. Most my messages would be returned to me.

Windows Live includes these tools:

  • Hotmail
  • Mail
  • Messenger
  • Toolbar
  • Spaces
  • Photo Gallery
  • Writer
  • Events
  • One Care

You get to choose which products you want when downloading the software.

DevConnections – Typed DataSets, LINQ-to-SQL, LINQ-to-Entities: Data Design Patterns Do Matter

This talk was given by Dino Esposito. Dino is a great speaker, and fun to watch. He’s very animated, and excited about what he’s talking about.

There are 3 principle architectural patterns for domain logic; Transaction Script (TS), Domain Model (DM), and Table Module (TM).

Transaction script has components mapped to required functionality. It’s simple but has the risk of duplicating code. This pattern is not ideal for .NET.

Domain model has each object map to a record. This is most flexible and the only pure object oriented option. This has no dependency on ADO.NET facilities.

Table module manages a table of data. A benefits is you have record set like data structures.

Ideally, opt for an architectural design pattern. Find the proper design pattern for the data source.

Data  source patterns:

  • Row Data Gateway – Table Module
  • Table Data Gateway – Table Module
  • Active Record – Domain Model
  • Data Mapper – Domain Model

Row data gateway has an object that acts as a gateway to a single record of data in a table of view. There is one instance per row. There is a direct correspondence between properties and columns. A row data gateway should contain only database access logic but no domain logic.

Table data gateway has an object that acts as a gateway to a table of data. It holds all the code to access a single table or view and perform CRUD methods.

What should a find by id method return?

  • Appropriate domain object if used with domain model.
  • A data set if used with table module.
  • A DTO filled with data only if used with transaction script.

This works well with table module.

Active record has an object that wraps a table or view row. It encapsulates database access. it exposes the same behavior through methods. It’s a domain model in which classes match closely the record of an underlying database table or view. There is no abstraction. The types are the same as the SQL types; no conversions. It leaves foreign keys as they are.

Typical methods for active records:

  • Create an instance of the object from SQL data.
  • Create an instance in memory for later insertion.
  • Has static finder methods for common queries.

A data mapper has mappers that move data between objects and a database table. It transfers data between in memory objects and related database tables.

Typed datasets:

  • What’s good?
    • Built in optimistic concurrency.
    • Handle complex relationships between tables.
    • Has serialization and persistence.
  • What’s bad?
    • Weakly typed and generic container.
    • No way to new up the individual data item.
    • Hard to deal with scalar values.

Collections and custom objects:

  • What’s good?
    • Strong typing and more compact objects.
    • Can represent data aggregated from multiple sources and free form.
    • Enables you to add behavior to objects, not table of objects.
  • What’s bad?
    • Manual coding of most features.

LINQ-to-SQL

  • There’s a clear trend to move business logic towards objects.
    • Real objects, not just data containers.
    • Data and behavior.
  • Domain model.
    • Simple schema through active record.
    • More complex schemas through data mapper.
  • LINQ’s query language on top of objects.
    • LINQ-to-SQL is a kind of active record.
    • LINQ-to-Entities is a kind of data mapper.
  • Use LINQ-to-SQL partial classes to create business domain layer and extend its functionality.
  • LINQ-to-Entities is the best way.