.NETified

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.

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.

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.

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.

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.

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.

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.

This talk was given by Michele Leroux Bustamante.

Michele went into a lot of detail about implementing globalization in ASP.NET. I have not done any globalization yet, so this was pretty much all new to me.

There are a few way you can do this. You can duplicate all the data and pages in each culture. A better way is to put all the culture strings into a resource, and pull the right one based on the user’s culture. You can use resources to manage assemblies, images, string, and more.

You can set the current threads culture based on the setting of the user’s web browser, or by a user setting. A user setting would be letting the user select the culture they want.

Her suggestions for globalization is, if there is any chance that you may need it, plan for it up front. You’ll save yourself months of rework.

She talked a little about output caching and the ways of doing this. ASP.NET kernel caching has 10x performance gain, where as user caching has 3x performance gain.

She talked about distribution of functionality. This is something I’ve heard that is a good thing to do, but no one has given me a reason as to why. Michele explained this quite well.

You should consider using a service boundary for security purposes. Instead of using a n-tier architecture, call a service that does the data access. This way, if a hacker compromises your site, they’ll only be able to go through your service, and won’t be able to access your data directly. To reduce the attack surface, use role based access for your service methods. Run with least privilege.

AJAX can only use HTTP services, so if you want to be secure, use a "router" service. The router will forward requests to the real service. Then you can verify that the request came only from the router.

Michele talked about load balancing considerations; what to do, and what not to do. I’ll write the to do here. Create new proxies and cache the channel. Limit downstream service calls.

Michele went in detail on these subjects and had many examples. I just touched the surface of her talk here.

This talk was given by Scott Hanselman and Eilon Lipton.

They did mostly examples, so I don’t have much to write about.

• They went into depth about how the update panel works. Eilon wrote the update panel, so it was interesting hearing him explain the internals of how it works. It basically will take all the code inside the panel, do an async request, and replace the code with what is returned from the request using the DOM.
• They talked a little about the ASP.NET AJAX Control Toolkit. Check out the site for more info. They can be pretty useful.
• With the script manager, you can enable page methods, and it will "export" .NET methods into Javascript.

This talk was given by Scott Hanselman and Eilon Lipton. Scott is the product manager in charge of the MVC framework, and Eilon the developer creating it.

This talk was mostly code examples.

• MVC FX is a new alternative to WebForms.
• Pluggable with IOC containers.
• Uses the Front Controller pattern.
• Only runs on .NET 3.5.
• It will be a new project type. It creates a solution with 2 projects in it. The website project, and a test project for the site.

For more information on the framework, check out Scott Hanselman’s post with a talk from himself and Scott Guthrie.