Rockford Lhotka's Blog

Home | | CSLA .NET

 Friday, November 18, 2005

I’ve posted a couple times before about what a business class will look like in the next edition of my business objects books and thus in CSLA .NET 2.0. One of those times Jason Bock (a fellow Magenicon) sent me an email asking why the DataPortal_Create/Fetch/Delete methods aren’t strongly typed.


If you look at the current approach and what I’ve posted thus far for the next edition you’ll see code like this:


Protected Overrides Sub DataPortal_Fetch(ByVal criteria As Object)


protected override void DataPortal_Fetch(object criteria)


Jason’s comment got me thinking. The DataPortal uses reflection to invoke this method, so why not be a bit more thorough in identifying the method’s parameters and invoke a strongly typed version like this:


Private Overloads Sub DataPortal_Fetch(ByVal criteria As Criteria)


void DataPortal_Fetch(Criteria criteria)


Where Criteria is the actual type of the criteria object provided when calling the DataPortal.Fetch() method back in the factory.


(the Overloads keyword is required because the base class still implements the default protected version)


As with many things, this sounded relatively trivial but turned out to be somewhat harder than expected. It is always the edge cases that make things hard… In this case the hard part is that parameters could be Nothing – in which case you don’t know what type they would be if they weren’t Nothing...


After working through that issue all is well.


This (in my opinion) is better than the alternative, which was to go with an interface-based approach and formalize the late-bound concept. That has its attraction, and people have altered CSLA .NET 1.0 along that line, but I really prefer strong typing if I can get it.


In particular this is nice for collections, where you may have multiple criteria classes for different views – now you can just implement a strongly-typed DataPortal_Fetch() method for each criteria class. Very clean and nice.


I’m still deliberating over whether to leave the default protected implementations in the base classes. They are nice because VS helps you override those methods, but they aren’t optimal. Given that VS has such nice snippet support it may be better to drop the protected defaults and just rely on snippets to insert the DataPortal_XYZ methods.


If you have an opinion, feel free to comment :)

Friday, November 18, 2005 6:02:25 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

This link was posted to the CSLA .NET discussion forum. It uses Google Maps and superimposes the locations of CSLA .NET users who've entered themselves on the site.

That's just way too cool! :)

Friday, November 18, 2005 12:16:08 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

ClickOnce is a great technology, but it seems that documentation is a bit scarce... In particular, like all web-based technologies, it requires some obscure configuration. The web may be great in some ways, but it does often require that you have a lot of arcane knowledge to do even the simplest thing...

This forum thread covers the little-documented fact that for IIS 6.0 the web server serving up a ClickOnce application needs to map the .application, .manifest and .deploy file types in IIS as follows:

.application -> application/x-ms-application
.manifest -> application/x-ms-application
.deploy -> application/octet-stream

While this may be documented somewhere, it seems quite hard to find. Thus I'm blogging it. If a few people blog the answers to common questions than at least google finds them for people :)

Friday, November 18, 2005 8:44:21 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, November 15, 2005

The ADO Guy expresses his frustration that the ObjectDataSource doesn't work with typed DataSets in ADO.NET 2.0. In an earlier post I expressed my frustration about using it with business objects.

In the case of CSLA .NET 2.0 I'm writing my own CslaDataSource that understands how to work nicely with CSLA .NET business objects. In conferring with the ASP.NET team it seems like this is the best option. It turns out that writing a DataSource control isn't overly difficult - it is writing the designer support (for VS 2005) that is the hard part...

Tuesday, November 15, 2005 9:55:10 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
Here's an article on MSDN that lists some nice add-ins for Visual Studio, and mentions other useful tools like ndoc as well.
Tuesday, November 15, 2005 8:56:45 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, November 02, 2005

Quite a few people have asked me about the effort that will be required to move an application from CSLA .NET 1.0 to CSLA .NET 2.0. The list of changes in the change log can look daunting after all…


Fortunately most of the changes in the change log are internal – they don’t directly impact your code in a business class all that much, at least for code written using more recent versions of the framework (1.3 or higher).


In fact, the closer your code is to version 1.51 (the current version) the easier the port will be. The closer to the original 1.0 version in the books the harder.


The three big change areas are generics, BrokenRules and the DataPortal.


Generics mean there are new and different base classes from which you inherit. In most cases changing to the new base class means removing some now unneeded code from your business class. The following table lists the base classes:





BusinessBase(Of T)


T = your business object type


BusinessListBase(Of T, C)

BusinessListBase<T, C>

T = your collection type

C = child object type


NameValueListBase(Of K, V)

NameValueListBase<K, V>

K = type of the key or name

V = type of the value


ReadOnlyBase(Of T)


T = your business object type


ReadOnlyListBase(Of T)


T = child object type


The only place where you need to add code is BusinessBase(Of T), where there’s a new GetIdValue method you must implement (typically with one line of code). In all cases you will remove code such as the System.Objects overrides region and tons of code in collections.


A much bigger changes is that BrokenRules has been replaced by ValidationRules and now only supports the idea of rule methods. The BrokenRules.Assert() concept is gone. This will be the biggest change for most people, as all Assert calls must be converted to rule methods. Fortunately that's not terribly hard, but it is work.


DataPortal used to call DataPortal_Update, forcing you to write a nested If..Then statement inside DataPortal_Update. It now calls DataPortal_Insert, DataPortal_Update or DataPortal_DeleteSelf as appropriate. So now you write 3 methods instead of 1, but each method is very focused and requires no conditionals. Also, DataPortal now calls MarkNew and MarkOld automatically so you don't need to make those calls (or forget to make them like I typically did...).


The end result is that all properties in a BusinessBase(Of T) business object will now look like this:


private string _name = string.Empty;


public string Name




    if (CanReadProperty())

      return _name;


      throw new System.Security.SecurityException(

        "Property get not allowed");




    if (CanWriteProperty())

      if (_name != value)


        _name = value;




      throw new System.Security.SecurityException(

        "Property set not allowed");






Private mName As String = ""


Public Property Name() As String


    If CanReadProperty() Then

      Return mName


      Throw New System.Security.SecurityException( _

        "Property get not allowed")

    End If

  End Get

  Set(ByVal value As String)

    If CanWriteProperty() Then

      If mName <> value Then

        mName = value


      End If


      Throw New System.Security.SecurityException( _

        "Property set not allowed")

    End If

  End Set

End Property



The new Expert VB/C# 2005 Business Objects books and thus the CSLA .NET 2.0 framework are slated for public release in Mar/Apr 2006.

Wednesday, November 02, 2005 10:08:19 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, November 01, 2005

When you install SP2 on Windows XP it tightens security to the point that MSDTC doesn't work any more. I'm sure this is good for most users, but renders a developer workstation virtually useless... There are a series of steps you follow to reenable MSDTC but changing both its configuration and the Windows Firewall configuration. I think the same thing is true for Windows Server 2003 actually.

I've done this numerous times, but I keep losing the link to the KB article (873160). So I'm putting it here in my blog so I won't lose it again.

Tuesday, November 01, 2005 1:04:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Feed your aggregator (RSS 2.0)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)

Powered by: newtelligence dasBlog 2.0.7226.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2016, Marimer LLC

Send mail to the author(s) E-mail

Sign In