I just posted a new preview version of 3.5 for download. The VB code includes a new concept around simplifying how child objects are persisted - create/fetch/insert/update/delete. The goal is to save code in root objects and list objects, and to standardize the coding model for all objects.
The code in the download is not completely tested, but basic tests all pass and so I think it is worth putting out for people to kick the tires. Regardless of whether you use C# or VB, if you get a chance to build some business classes against the VB framework your feedback would be invaluable!
I want to be very clear that this is all entirely optional. If you don't like it (because it does use reflection just like the data portal always has) then you can continue to use the model from 3.0 and earlier. Nothing compels you to use this new model (except for radical simplification of code ![Wink [;)]](/emoticons/emotion-5.gif)
), and if you don't use it then you incur no extra overhead or cost.
The new child object pattern is this:
[Serializable]
public class Child : BusinessBase<Child>
{
internal static Child NewChild()
{
return DataPortal.CreateChild<Child>();
}
internal static Child GetChild()
{
return DataPortal.FetchChild<Child>();
}
private Child()
{
MarkAsChild();
}
private void Child_Create()
{
// initialize new child here
}
private void Child_Fetch()
{
// load child data here
}
private void Child_Insert()
{
// insert child data here
}
private void Child_Update()
{
// update child data here
}
private void Child_DeleteSelf()
{
// delete child data here
}
}
Please note that no calls to MarkNew() or MarkOld() are required, they are all handled by the data portal just like they are for root objects.
The new editable root (parent) pattern is this:
[Serializable]
public class RootParent : BusinessBase<RootParent>
{
// other class code here ...
protected override void DataPortal_Insert()
{
using (SqlConnection cn = new SqlConnection(...))
{
// insert parent data here
FieldManager.UpdateChildren();
}
}
protected override void DataPortal_Update()
{
using (SqlConnection cn = new SqlConnection(...))
{
// update parent data here
FieldManager.UpdateChildren();
}
}
}
The call to UpdateChildren() automatically cascades appropriate insert/update/delete calls to all child objects (including collections).
The new editable root list pattern is this:
[Serializable]
public class ChildList : BusinessListBase<ChildList, Child>
{
// other class code here ...
protected override void DataPortal_Update()
{
using (SqlConnection cn = new SqlConnection(...))
{
Child_Update();
}
}
}
The only reason you still need to override DP_Update() is so you can manage the connection details (or LINQ context, or whatever).
The new editable child list pattern is this:
[Serializable]
public class ChildList : BusinessListBase<ChildList, Child>
{
internal ChildList()
{
MarkAsChild();
}
// other class code here ...
}
Notice that there is no data access code here, because child updates are now handled entirely by the base class.
Rocky