There is an extremely cool code snippets editor on the tools menu of VS.  Basically is adds stuff to intellisense.

I created a new folder for Strataframe snippets.  Here is an example of a Custom Field Property snippet

( this is instead of cutting and pasting from the bo.designer generated code as in the beginner tutorial. Note that the string datatype is hardcoded so either make a $replacement$ for it or remember to change it if your custom field prop isn't string 

#Region " Custom Field Properties "

''' <summary>

''' $Custom Field Description$

''' </summary>

''' <remarks></remarks>

<Browsable(False), _

BusinessFieldDisplayInEditor(), _

Description("$Custom Field Description$"), _

DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _

Public ReadOnly Property [$Property Name$]() As System.String

Get

Return $Property Value$

End Get

End Property

Protected Overrides Function GetCustomBindablePropertyDescriptors() As MicroFour.StrataFrame.Business.FieldPropertyDescriptor()

'-- Create and return a new array of FieldPropertyDescriptor

' objects that contains the ReflectionPropertyDescriptor

' for the $Property Name$ field.

Return New MicroFour.StrataFrame.Business.FieldPropertyDescriptor() { _

New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _

"$Property Name$", GetType($BOName$))}

End Function

#End Region

On the Imports tab you enter the stuff that must be imported for this to work

System.ComponentModel

Microfour.Strataframe.UI.Windows.Forms

For a shorcut I used cpr

Now if you are in the BO code, you just but the cursor under the Event Handlers region, type cpr, hit tab and everthing you see above gets typed in with the cursor on the first Replacement.  You fill it in, tab to the next one etc.

If the imports statements are not at the top of the declaration, the snippet editor puts them in !

I think this is cool and I'm pretty sure I've only scratched the surface of the possiblities here.

You may not see the Code Snippet Editor on the Tools menu ( for some reason mine didn't have it ) but if you Google you'll find it for download with easy instructions to install in.  Comes with a lot of predone VB stuff as well.

I've added

FillbyParam ( fbp )

Public Sub Fillby$Subname$(ByVal $param1$ As String)

'-- Establish locals

Dim loCommand As New SqlCommand()

We too are from a VFP background and used to rely heavily on data dictionaries...which in our medical application we are doing everything that we can to get away from it!  There are better (and more efficient) ways of accomplishing the same thing in .NET.  One thing that most developers moving over from VFP have a hard time initially grasping is disconnected data.  When we were developing in VFP, you opened a table and BOOM...all of your records were there.  Even if you were using views it still had to bring the data to the client to do the work since there was not a server.

Relying heavily on a data dicitonary in a disconnected data application (which will be any application from this point forward) can create a slow and unresponsive application.  Thus most develpoers take a different approach.  It took us a while when we first stepped into .NET and disconnected data from VFP because we were trying to basically use the same techniques on a new technology....which just won't work...and it shouldn't.

I think that as you move forward you will discover hundreds of new things that will make your life much easier and better...so though at first glance it appears as though there has been a step back or two, that is just because we have generally been trying to look at it from the same perspective as when we were developing in VFP when there is ultimately a better and more efficient way in .NET.

This is the first problem...you should not be reproducing the same code again anyway!  A business object represents an entity such as a table or view in a database.  You should have ONE primary BO that represents this entity.  Then if you have a scenario, such as a report, that will extend this business object, then you will create another BO and inherit off of the primary business object.  So it will inherit the logic of the parent.

You NEVER change the designer file as anything you change in this class will be overwritten when you rebuild through the BO Mapper.  Add all of your custom code in the MyBo.vb or MyBo.cs file.  This is the beauty of partial classes, you can have a single class declaration spread accoss multiple physical files.  The way you use this logic on another BO is by inheriting this BO class on the other BO.

There are ways to do this, but you will first have to change the way that you current are used to working with data.  Most VFP developers (including ourselves) have a hard time learning to deal with disconnected data.  Depending on what you are trying to accomplish you may want to do some of this at the BO level by handling the field changed events or one of the many other events of the BO.  You can add handler events at the column level or intercept an event anytime ANY field is changed (or accessed).  You can see how to add this type of logic in the help docs under the Application Framework -> Business Layer -> Business Object Mapper -> Dynamic Business Object Events.

Secondly, here, some of this may be done at the database level, again depending on what you are trying to accomplish.  SQL Server is far superior to VFP databases and tables in every aspect (and this is coming from a once die-hard VFP guy ) but requires a change in thinking.  There are triggers and cascades just like in VFP that can be handled here as well. 

You should not be adding custom code at the DAL.  You can however handle events that affect what the DAL actually does, but the DAL is the connectivity layer that communicates to the database and should be transparent.  I think that some of the Data Access Layer that you are referring to is actually going to be handled in the business layer or related events.