I always encourage people to go with 2-tier deployments if possible, because more tiers increases complexity and cost.

But it is important to recognize when the value of 3-tier outweighs that complexity/cost. The primary three motivators are:

1. Security – using an app server allows you to shift the database credentials from clients to the server, adding security because a would-be hacker (or savvy end-user) would need to hack into the app server to get those credentials.
   
2. Network infrastructure limitations – sometimes a 3-tier solution can help offload processing from CPU-bound or memory-bound machines, or it can help minimize network traffic over slow or congested links. Direct database communication is a chatty dialog, and using an app server allows a single blob of data to go across the slow link, and the chatty dialog to occur across a fast link, so 3-tier can result in a net win for performance if the client-to-server link is slow or congested.
   
3. Scalability – using an app server provides for database connection pooling. The trick here, is that if you don’t need it, you’ll harm performance by having an app server, so this is only useful if database connections are taxing your database server. Given the state of modern database hardware/software, scalability isn’t a big deal for the vast majority of applications anymore.

The CSLA .NET data portal is of great value here, because it allows you to switch from 2-tier to 3-tier with a configuration change - no code changes required*. You can deploy in the cheaper and simpler 2-tier model to start with, and if one of these motivators later justifies the complexity of moving to 3-tier, you can make that move with relative ease.

* disclaimer: if you plan to make such a move, I strongly suggest testing in 3-tier mode during development. While the data portal makes this 2-tier to 3-tier switch seamless, it only works if the code in the business objects follows all the rules around serialization and layer seperation. Testing in a 3-tier mode helps ensure that none of those rules get accidentally broken during development.

Magenic is producing a series of webcasts on various IT related topics. One of them is CSLA .NET, and I'll be the speaker for that webcast. Click here for details on the date/time and how to register.

I was recently asked whether CSLA incorporates thread synchronization code to marshal calls or events back onto the UI thread when necessary. The short answer is no, but the question deserves a bit more discussion to understand why it isn't the business layer's job to handle such details.

The responsibility for cross-thread issues resides with the layer that started the multi-threading.

So if the business layer internally utilizes multi-threading, then that layer must abstract the concept from other layers.

But if the UI layer utilizes multi-threading (which is more common), then it is the UI layer's job to abstract that concept.

It is unrealistic to build a reusable business layer around one type of multi-threading model and expect it to work in other scenarios. Were you to use Windows Forms components for thread synchronization, you'd be out of luck in the ASP.NET world, for example.

So CSLA does nothing in this regard, at the business object level anyway. Nor does a DataSet, or the entity objects from ADO.NET EF, etc. It isn't the business/entity layer's problem.

CSLA does do some multi-threading, specifically in the Csla.Wpf.CslaDataProvider control, because it supports the IsAsynchronous property. But even there, WPF data binding does the abstraction, so there's no thread issues in either the business or UI layers.

As long as I'm doing simple blog links, here's another tool worth looking at, if you need to skin a SharePoint or other web site: 

SharePoint Skinner Overview - eLumenotion Blog

I haven't tried this yet, but it looks like a very nice tool for WPF developers:

Woodstock for WPF - The Code Project - Windows Presentation Foundation

I was recently asked how to get the JSON serializer used for AJAX programming to serialize a CSLA .NET business object.

From an architectural perspective, it is better to view an AJAX (or Silverlight) client as a totally separate application. That code is running in an untrusted and terribly hackable location (the user’s browser – where they could have created a custom browser to do anything to your client-side code – my guess is that there’s a whole class of hacks coming that most people haven’t even thought about yet…)

So you can make a strong argument that objects from the business layer should never be directly serialized to/from an untrusted client (code in the browser). Instead, you should treat this as a service boundary – a semantic trust boundary between your application on the server, and the untrusted application running in the browser.

What that means in terms of coding, is that you don’t want to do some sort of field-level serialization of your objects from the server. That would be terrible in an untrusted setting. To put it another way - the BinaryFormatter, NetDataContractSerializer or any other field-level serializer shouldn't be used for this purpose.

If anything, you want to do property-level serialization (like the XmlSerializer or DataContractSerializer or JSON serializer). But really you don’t want to do this either, because you don’t want to couple your service interface to your internal implementation that tightly. This is, fundamentally, the same issue I discuss in Chapter 11 of Expert 2005 Business Objects as I talk about SOA.

Instead, what you really want to do (from an architectural purity perspective anyway) is define a service contract for use by your AJAX/Silverlight client. A service contract has two parts: operations and data. The data part is typically defined using formal data transfer objects (DTOs). You can then design your client app to work against this service contract.

In your server app’s UI layer (the aspx pages and webmethods) you translate between the external contract representation of data and your internal usage of that data in business objects. In other words, you map from the business objects in/out of the DTOs that flow to/from the client app. The JSON serializer (or other property-level serializers) can then be used to do the serialization of these DTOs - which is what those serializers are designed to do.

This is a long-winded way of saying that you really don’t want to do JSON serialization directly against your objects. You want to JSON serialize some DTOs, and copy data in/out of those DTOs from your business objects – much the way the SOA stuff works in Chapter 11.

I've worked at numerous clients who've done offshoring projects, and for the most part I've watched the potential savings evaporate due to various factors (typically a ton of rework on the back end, as the clients ended up spending months "fixing" the software so it would actually meet their needs).

Having watched that happen, I always wanted to write a blog post detailing the issues, risks and costs. Now I don't have to because a fellow Magenicon has done a really nice job with this article: 

Latest in Offshoring to India: Considerations in Evaluating Onshore vs. Offshore Software Development

Interestingly enough, I would be that a lot of that rework I've seen happen at these clients would not have been necessary if they'd recognized the real costs and risks ahead of time - most of which are covered in Matt's article. By recognizing the real risks ahead of time, it would have been possible to put procedures in place, and assign local resources to the project up front to help mitigate or manage those risks. Sure, doing those things does eat into the savings, but would almost certainly help avoid the incredibly costly rework that is otherwise required on the back end of the project.

My brother manages a global team. His team exists in the US, France, India and Japan. They do 24 hour development. He has a lot of interesting stories to tell about cultural communication barriers (missing deadlines because a US phrase meaning "we'll get it done" means "we'll think about it" in another country, that sort of thing). And the joy of rotating conference calls through all hours of the day and night so the team can coordinate and so no one nation's team has to get up at 2 AM all the time. I've stayed at his house when he had to get up for a 2 AM conference call - what fun!

But his team is successful. After years of working through the various issues, and using a high level of process and formalization (he's a Six Sigma Black Belt and instructor), they have been able to get this all working. Prior to having that level of formalization and rigor of process though, I know they really struggled.

So the costs and risks associated with offshoring are very real. Whether they make local resources cheaper or not is a case-by-case thing, but it is clearly ridiculous to expect a huge savings by offshoring after you factor in all the issues involved.

My email provider just emailed me to let me know that emails to my lhotka.net addresses (and in particular my admin @ lhotka.net address) may have been lost between October 10-14.

I am posting this on my blog, because that admin address is the location people email to get support from http://store.lhotka.net.

So if you emailed me for support or help with purchasing my ebooks within the past few days, and I haven't responded, it is probably because the emails were lost. Please email me again and I'll do what I can to help resolve any issues.

Thank you!

   

Now available in both VB and C# editions!

CSLA .NET version 3.0 adds support for Microsoft .NET 3.0 features. This ~120 page ebook covers how to use these new capabilities:

• Windows Presentation Foundation (WPF)
  • Creating WPF forms using business objects
  • Using the new controls in the Csla.Wpf namespace
    • CslaDataProvider
    • Validator
    • Authorizer
    • ObjectStatus
    • IdentityConverter
  • Maximizing XAML and minimizing C#/VB code
• Windows Communication Foundation (WCF)
  • Using the new WCF data portal channel to seamlessly upgrade from Remoting, Web services or Enterprise Services
  • Building WCF services using business objects
  • Applying WCF security to encrypt data on the wire
  • Sending username/password credentials to a WCF service
    • Including use of the new Csla.Security.PrincipalCache class
  • Using the DataContract attribute instead of the Serializable attribute
• Windows Workflow Foundation (WF)
  • Creating activities using business objects
  • Invoking a workflow from a business object
  • Using the WorkflowManager class in the Csla.Workflow namespace

Version 3.0 is an additive update, meaning that you only need to use the .NET 3.0 features if you are using .NET 3.0. CSLA .NET 3.0 is useful for people using .NET 2.0!! These features include:

• Enhancements to the validation subsystem
  • Friendly names for properties
  • Better null handling in the RegExMatch rule method
  • New StringMinLength rule method
  • Help for code generation through the DecoratedRuleArgs class
• Data binding issues
  • Fixed numerous bugs in BusinessListBase to improve data binding behavior
  • Throw exception when edit levels get out of sync, making debugging easier
  • N-level undo changed to provide parity with Windows Forms data binding requirements
• AutoCloneOnUpdate
  • Automatically clone objects when Save() is called, but only when data portal is local
• Enhancements to the authorization subsystem
  • CanExecuteMethod() allows authorization for arbitrary methods

CSLA .NET 3.0 includes numerous bug fixes and some feature enhancements that benefit everyone. If you are using version 2.0 or 2.1, you should consider upgrading to 3.0 to gain these benefits, even if you aren't using .NET 3.0.

See the change logs for version 3.0, version 3.0.1 and version 3.0.2 for a more detailed list of changes.

Using CSLA .NET 3.0 is completely focused on how to use the new features in version 3.0. The book does not detail the internal changes to CSLA .NET itself, so all ~120 pages help you use the enhancements added since version 2.1.

Get the book at store.lhotka.net.

Download the 3.0.2 code from the CSLA .NET download page.

Earlier this week I co-presented a session at ReMIX in Boston, with Anthony Handley, a fellow Magenicon. Anthony is a User Experience Specialist, and the two of us have been working on a WPF/Silverlight project (that also happens to use CSLA .NET of course :) ) and in this presentation we discussed our experiences using WPF from the perspectives of a developer and a designer.

Here are the links to the video of the session.

Real World Experiences Building Applications Using WPF and Silverlight

Part 1
http://channel9.msdn.com/Showpost.aspx?postid=346810
Part 2
http://channel9.msdn.com/Showpost.aspx?postid=346812
Part 3
http://channel9.msdn.com/Showpost.aspx?postid=346815
Part 4
http://channel9.msdn.com/Showpost.aspx?postid=346818

I recently branched the CSLA .NET codebase in the svn repository (www.lhotka.net/cslacvs for a web view).

Version 3.0.3, which is the maintenance branch for the current 3.0.2 version, is on a branch now. This is a VS 2005 solution (though ProjectTracker does include some VS 2008 projects for .NET 3.0 concepts).

Active development is still on the trunk, and is for version 3.5. I'll be switching that version to a VS 2008 solution in the near future.

Switching to VS 2008 is a big deal. I realize that many people will be using VS 2005 for a long time to come, and so I don't do this lightly.

However, CSLA .NET 3.5 will include features around LINQ and other .NET 3.5 concepts. As such, I must use VS 2008 to do that work, because that is the tool for .NET 3.5 (and really for .NET 3.0).

If possible, I'll continue to use the compiler directive approach to allow building Csla.dll for .NET 2.0, 3.0 and 3.5. Whether this is realistic or not depends on the level at which LINQ ends up integrating into the framework. If LINQ gets too deep, the complexity introduced by the compiler directive approach may become higher than I'm willing to deal with, at which point I'll drop that idea. But for now, my goal is to continue to allow backward targeting of the framework.

Fortunately VS 2008 itself also supports backward targeting, so it is possible to use VS 2008 to build assemblies for .NET 2.0, 3.0 or 3.5. This may help mitigate some of the pain of having the Csla project switch to 2008, because you can still use 2008 to build for a .NET 2.0 deployment environment.

In CSLA .NET 3.0 I implemented Csla.Wpf.Validator. This control provides functionality similar to the Windows Forms ErrorProvider control, only in WPF. Of course the ErrorProvider relies on the standard IDataErrorInfo interface, which CSLA supports on behalf of your business objects, and so my Validator control used that same interface.

While I was researching and designing the Validator control, I was in contact with the WPF product team. As a result, I had (shall we say) a "strong suspicion" that my control was a temporary stop-gap until Microsoft provided a more integrated solution. And that's fine - we needed something that worked, and Validator was the ticket.

This blog post provides some good, detailed, insight into the real solution in .NET 3.5: 

Windows Presentation Foundation SDK : Data Validation in 3.5

A couple people have emailed me, asking what I think about this. My answer: I'm happy as can be!

As I say, I knew Validator was temporary. WPF is a version 1.0 technology, and it is very clear that Microsoft will be evolving it rapidly over the next few years. And it is equally clear that WPF must evolve to catch up to, and hopefully exceed, Windows Forms. That means more robust data binding support, including an ErrorProvider equivalent.

So to me, this just means that CSLA .NET 3.5 can drop the Validator control, because there's now a directly supported solution in .NET itself. While this will require changing XAML when moving from .NET 3.0 to 3.5, it is a worthwhile change to make.

The VB version of CSLA .NET 3.0.2 is now officially available. For details see this post, and to download the code go to www.lhotka.net/cslanet/download.aspx.

The VB edition of Using CSLA .NET 3.0 is in final review and should be available within a few days.

CSLA .NET version 3.0 adds support for Microsoft .NET 3.0 features. This ~120 page ebook covers how to use these new capabilities:

• Windows Presentation Foundation (WPF)
  • Creating WPF forms using business objects
  • Using the new controls in the Csla.Wpf namespace
    • CslaDataProvider
    • Validator
    • Authorizer
    • ObjectStatus
    • IdentityConverter
  • Maximizing XAML and minimizing C#/VB code
• Windows Communication Foundation (WCF)
  • Using the new WCF data portal channel to seamlessly upgrade from Remoting, Web services or Enterprise Services
  • Building WCF services using business objects
  • Applying WCF security to encrypt data on the wire
  • Sending username/password credentials to a WCF service
    • Including use of the new Csla.Security.PrincipalCache class
  • Using the DataContract attribute instead of the Serializable attribute
• Windows Workflow Foundation (WF)
  • Creating activities using business objects
  • Invoking a workflow from a business object
  • Using the WorkflowManager class in the Csla.Workflow namespace

Version 3.0 is an additive update, meaning that you only need to use the .NET 3.0 features if you are using .NET 3.0. CSLA .NET 3.0 is useful for people using .NET 2.0!! These features include:

• Enhancements to the validation subsystem
  • Friendly names for properties
  • Better null handling in the RegExMatch rule method
  • New StringMinLength rule method
  • Help for code generation through the DecoratedRuleArgs class
• Data binding issues
  • Fixed numerous bugs in BusinessListBase to improve data binding behavior
  • Throw exception when edit levels get out of sync, making debugging easier
  • N-level undo changed to provide parity with Windows Forms data binding requirements
• AutoCloneOnUpdate
  • Automatically clone objects when Save() is called, but only when data portal is local
• Enhancements to the authorization subsystem
  • CanExecuteMethod() allows authorization for arbitrary methods

CSLA .NET 3.0 includes numerous bug fixes and some feature enhancements that benefit everyone. If you are using version 2.0 or 2.1, you should consider upgrading to 3.0 to gain these benefits, even if you aren't using .NET 3.0.

See the change logs for version 3.0, version 3.0.1 and version 3.0.2 for a more detailed list of changes.

Using CSLA .NET 3.0 is completely focused on how to use the new features in version 3.0. The book does not detail the internal changes to CSLA .NET itself, so all ~120 pages help you use the enhancements added since version 2.1.

Get the book at store.lhotka.net.
(C# available now, VB available in early October)

Download the 3.0.2 code from the CSLA .NET download page.

It is a reasonably well-known fact that WPF misuses the Equals() method in the data binding implementation.

If you set a DataContext to an object, then set it to another object that is logically equal to the first, but which has different data, WFP gladly ignores the new object's data:

form.DataContext = A;
B = A.Clone();
B.Value = "new value";
form.DataContext = B;

Assuming A and B retain logical equality even though Value has changed, this code results in the UI not showing the new value. Apparently the reasoning is that if the objects are equal, then there's no need to update any data through data binding.

Of course this totally confuses ReferenceEquals() with Equals(), and the result is that objects used by WFP can no longer have logical equality. They can only have reference equality.

(or, arguably, WPF forces 100% property-level equality across objects, so equality can extend to two different instances as long as they have absolutely no different property values - which seems entirely useless)

In .NET 3.0 I had a solution, at least in CslaDataProvider. The solution was to temporarily set the DataContext to null, then to the new object. The result was that the faulty (imo anyway) equality comparison was defeated.

Unfortunately, it appears that .NET 3.5 may have "fixed a bug" that prevents this from working. The result is that it appears there is NO WAY TO REFRESH DATA when fields of an object change, but the object's logical identity remains the same.

I'm not yet sure of a final solution. The current situation is very bad, because you can either use WPF or you can have logical equality between objects - but not both.

It might be the case that people who need logical equality will have to implement their own parallel Equals() concept - ignoring the standard one built into .NET. That's a really poor solution, but if Microsoft isn't going to use their own framework responsibly then we're kind of stuck. Of course operators become an issue then, since operator overloading is related to Equals() as well. I suppose you could break that relationship, but then you'd get really odd stuff like this:

x = y is true

x.Equals(y) is false

But if WPF forces Equals() to be ReferenceEquals() instead of actual equality, then we come back to being stuck.

I love WPF - it is really cool. But this particular issue is a real problem. Apparently one without a real solution.