Sometimes the PropertyInfo<T> fields are public. In fact I've taken to usually making them public, as it makes it far easier to build your DAL using an ObjectFactory.
If they are public, then someone could change the property at any time while the app is running, leading to unpredictable results. In reality, the PropertyInfo<T> objects should be considered to be read-only tokens representing each property.
However, they don't actually have to be static fields. Nor do they need to be in your business class. The only real constraint is that they be initialized before any code tries to interact with an instance of your business object(s) - including deserialization of a data portal call.
In other words, it is totally realistic to have some type of initialization routine in your application that loads all the PropertyInfo<T> objects as the app starts up - perhaps using metadata - as long as this occurs before any attempted use of the business objects. And of course, the initialization would need to be run on both the client and app server (and intermediate web server in the 4-tier Silverlight scenario).
My problem is that while you may be willing to live with
the risk, I’m not sure the other users of CSLA would be happy to accept
it :)
Putting the RegisterProperty() calls outside the business class
is very much an advanced scenario, and is not covered in the book. For most
people it isn’t appropriate, but it does enable some interesting
variations in some cases. It looks somewhat like this, though this is not the only
possible approach:
public static class CustomerMeta
{
public static PropertyInfo<string> NameProperty;
}
public class AppData
{
public void InitializeApp()
{
CustomerMeta.NameProperty =
RegisterProperty<string>(typeof(Customer), “Name”);
}
}
[Serializable]
public class Customer : BusinessBase<Customer>
{
public string Name
{
get { return
GetProperty(CustomerMeta.NameProperty); }
set { SetProperty(CustomerMeta.NameProperty, value);
}
}
}
The only catch with this, is that AppData.InitializeApp() must
be run before Customer is used or you’ll get exceptions. And you must
run InitializeApp() on the client and app server.
The value here, is that InitializeApp() can do the
RegisterProperty() calls using metadata, perhaps in a way that you couldn’t
do when calling RegisterProperty() as a static field initializer.
Rocky
RockfordLhotka:
My problem is that while you may be willing to live with the risk, I’m not sure the other users of CSLA would be happy to accept it :)
My problem is that while you may be willing to live with
the risk, I’m not sure the other users of CSLA would be happy to accept
it :)
Putting the RegisterProperty() calls outside the business class
is very much an advanced scenario, and is not covered in the book. For most
people it isn’t appropriate, but it does enable some interesting
variations in some cases. It looks somewhat like this, though this is not the only
possible approach:
public static class CustomerMeta
{
public static PropertyInfo<string> NameProperty;
}
public class AppData
{
public void InitializeApp()
{
CustomerMeta.NameProperty =
RegisterProperty<string>(typeof(Customer), “Name”);
}
}
[Serializable]
public class Customer : BusinessBase<Customer>
{
public string Name
{
get { return
GetProperty(CustomerMeta.NameProperty); }
set { SetProperty(CustomerMeta.NameProperty, value);
}
}
}
The only catch with this, is that AppData.InitializeApp() must
be run before Customer is used or you’ll get exceptions. And you must
run InitializeApp() on the client and app server.
The value here, is that InitializeApp() can do the
RegisterProperty() calls using metadata, perhaps in a way that you couldn’t
do when calling RegisterProperty() as a static field initializer.
Rocky
Copyright (c) Marimer LLC