ASP.Net to Blazor Migration

[jmpotvin]

I'm working on a project to transition an ASP.Net 4.8 WebForms application with over 1600 CSLA classes (mostly CSLA 4, some from VB 2008 Business Objects) to a Blazor application using Yarp and CSLA 7.X.

This migration presents two main challenges:

1. DataPortal Adaptation
Our traditional approach involved encapsulating data functions within business classes. To facilitate smoother migration, we've abstracted the data provider, now utilizing Dapper directly in the business classes.
Here's a simplified fictional class example:

[Serializable]
public class UserInfo : ReadOnlyBase<UserInfo>
{
    
    public static readonly PropertyInfo<string> FullNameProperty = RegisterProperty<string>(nameof(FullName));
    public string FullName
    {
        get => GetProperty(FullNameProperty);
        private set => LoadProperty(FullNameProperty, value);
    }

    [Fetch]
    private async Task FetchAsync(string userName, [Inject] IDbProvider dbProvider)
    {
        using (IDbConnection connection = dbProvider.GetConnection())
        {
            connection.Open();
            DbParameters p = new DbParameters();
            p.Add("pUserName", userName.ToUpper());

            string sql = @$"select t.full_name
                            from table t
                            where t.username = :pUserName";

            var data = await dbProvider.QueryFirstAsync(connection, sql, p, commandType: CommandType.Text);
			
            FullName = data.FULL_NAME;
        }
    }
}

Are there potential issues with this direct approach?
Do any other projects on GitHub follow a similar approach?

2. Long-Term Migration Strategy
Given that this is a multi-year project, we anticipate encountering new CSLA versions, potentially introducing breaking changes. This concern led to my earlier post, "Abstraction Between Blazor Server and CSLA."

Is it feasible to have multiple CSLA Business Libraries, each on different CSLA versions (7.* or newer), coexist in the same Blazor Web Application?

Thank you for your assistance.

[rockfordlhotka]

This is a valid way of implementing a data access layer, discussed in the Using CSLA: Data Access book.

It has the advantage of being the simplest model, and perhaps the fastest as it has the least abstraction. It has the disadvantage of having little abstraction and so if your data access tooling/framework changes over time you'll have to fix the code in every domain class.

It is possible, with some work, to use multiple versions of CSLA at the same time. You need to build your own version of the CSLA assemblies, and change the namespace from Csla to a version-specific thing like Csla70 or something - then make sure you are using the right namespace for the version you want to use within a specific subset of your code.

There may be other challenges with older versions of CSLA around settings and ApplicationContext - I'm not 100% sure. I suspect that with CSLA 7+ most of those potential issues are mitigated by the fact that ApplicationContext is now (mostly) an instanced service instead of a bunch of static values.