Upgrading from CSLA 4.6.5 to 6.2 in ASP.NET

[DMFullbrook]

We use CSLA 4.6.5 in an ASP.NET Web project based on .NET Framework 4.6.1. Have you got any example of how to implement the new DI for CSLA 6.2 in an ASP.NET Web project based in .NET Framework 4.8?

[rockfordlhotka]

Have you seen this?

https://github.com/MarimerLLC/csla/blob/main/docs/Upgrading%20to%20CSLA%206.md

[DMFullbrook]

Yes, I read that but I couldn't see an example using ASP.NET Framework. Our projects are all based on CSLA 4.6,1 and, as well as using Linq To SQL, use the DalFactory method to load a Mock or LingToSQL DLL for unit testing (as described in one of your books - I forget which). It seems there would be an enormous amount of work to bring all our Business Libraries (65 at last count) up to CSLA 6.2. I have also tried CSLA 5.5.3 which does not require DI and is less of a change - will CSLA 5.3.3 continue to be around and supported for some time?

[rockfordlhotka]

I'll confess that I haven't used ASP.NET for many years, and I haven't paid attention to how or if it integrates with "modern" DI coding techniques.

As you can see in that document I linked, some older UI frameworks (WinForms, WPF, Xamarin) can use what's called a service locator pattern, where a global instance of the DI provider is exposed via a public static property.

I don't know if you can do this in ASP.NET or not. I kind of suspect it might work, because CSLA maintains per-user state in HttpContext when running in ASP.NET, so it wouldn't (hopefully) leak data across multiple concurrent user sessions.

[rockfordlhotka]

To answer your follow-up question about v5.x, "supported" is a complex term when talking about open-source products.

Personally, I'm spending all my time on v7, though I recently did apply a high priority fix to v6. I have no intention of personally applying updates to v5.

That said, if someone took a v6 or v7 feature or bug fix and could figure out how to back-port it to v5, I would likely accept such a pull request. Realistically though, other than small bug fixes, it would be very hard to backport anything from v6 to v5 given the complete dependency on DI in v6 and later.

[DMFullbrook]

Many thanks for your reply. I'm almost certain that the service locator pattern would work in ASP.NET so I'm not unduly concerned about that. The bigger issue I have is the loss of LinqToSql (see #3181), and the sheer size of our business library that would need extensive rework. I have to ask - why have you introduced DI and dropped backwards compatibility?

[rockfordlhotka]

I think you can solve the L2S issue by grabbing the connection manager class from v4 and putting it in your project. It isn't that it won't work, it is just that in "modern" code people use DI to solve the problem.

In terms of embracing DI, that was necessary to support aspnetcore and Blazor. Microsoft has started using DI scopes to maintain things like per-user state, and if we didn't follow their lead then CSLA wouldn't work with "modern" web development in .NET. The changes to fully embrace DI were extensive, and it was a one-way journey that we had to take.

Users like you that are staying on .NET Framework (netfx) and ASP.NET classic should expect to find more and more software that drops support for netfx and ASP.NET. It has been an ongoing conversation in the open-source world, as it is such a big break in capability from the older framework to modern .NET, that a lot of OSS leaders are saying they can't target both going forward.

I'm not disparaging your choice. I fully understand it, being pretty reserved myself when working with clients! There are consequences to that choice though, and they'll get worse as time goes on - like with any legacy platform.

[DMFullbrook]

Many thanks for taking the time to replay Rocky. At least we know where we stand! Not sure we can spare probably more than 3 months of Development effort to basically (from a User standpoint) stand still. As you say it’s a problem that will only get worse. But the problem I have with that is that I’ll be back here again in 4-5 years when DI has been dropped for something else (you get the point). Much thinking to be done (not least can we afford the spend while Users perceive we are doing nothing). The Boss says no! From: Rockford Lhotka ***@***.***> Sent: 03 November 2022 15:37 To: MarimerLLC/csla ***@***.***> Cc: David Fullbrook ***@***.***>; Author ***@***.***> Subject: Re: [MarimerLLC/csla] Upgrading from CSLA 4.6.5 to 6.2 in ASP.NET (Discussion #3179) I think you can solve the L2S issue by grabbing the connection manager class<https://github.com/MarimerLLC/csla/tree/v4.x/Source/Csla.Shared/Data> from v4 and putting it in your project. It isn't that it won't work, it is just that in "modern" code people use DI to solve the problem. In terms of embracing DI, that was necessary to support aspnetcore and Blazor. Microsoft has started using DI scopes to maintain things like per-user state, and if we didn't follow their lead then CSLA wouldn't work with "modern" web development in .NET. The changes to fully embrace DI were extensive, and it was a one-way journey that we had to take. Users like you that are staying on .NET Framework (netfx) and ASP.NET classic should expect to find more and more software that drops support for netfx and ASP.NET. It has been an ongoing conversation in the open-source world, as it is such a big break in capability from the older framework to modern .NET, that a lot of OSS leaders are saying they can't target both going forward. I'm not disparaging your choice. I fully understand it, being pretty reserved myself when working with clients! There are consequences to that choice though, and they'll get worse as time goes on - like with any legacy platform. — Reply to this email directly, view it on GitHub<#3179 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3JT5CIMVEV3BT4GTI4CKLTWGPL27ANCNFSM6AAAAAART4G4MY>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[tabaguley]

This thread caught my eye, as I have dealt extensively with CSLA & .NET codebase upgrades over the years. Most recently, I worked on a rebuild of ASP.NET WebForms project (built on .NET Framework 1.1 and and CSLA 1.7 -- YES, that old!!). The site is now running quite nicely using:

• ASP.NET Core Web App (using Razor Pages; on .NET 6 -- began with .NET Core 2, then 3, 3.1, then .NET 5 ... each upgrade was seamless)
• .NET Standard 2.1 (All Business Object Code)
• CSLA 5.3+ (With a good bit of in-house, bolt-on customization)

We are currently analyzing and assessing CSLA 6+ and will likely move to that soon. However, given the majority of our applications are Windows Forms based, .NET Framework 4.8 for those, .NET 6+ for Web, and CSLA 5.3 (with our customizations) will continue to work perfectly fine for the foreseeable future.

To address a couple of your particular concerns:

LinqToSql ... For those of us who have coded using Microsoft's technologies for any length of time (over two decades in my case), you know that every few years or so there comes along some to wiz-bang way to move data between a data source/store and code/UI. And usually, adopting that new technology means a major rewrite or overhaul to your codebase. Because of this, I have never been a fan of using anything like LinqToSql, Entity Framework, etc. Instead, I created a built-in data access layer (of sorts) which basically bolts on to CSLA. From there, all necessary Properties in a business object which have a corresponding field in the database receive a DataField Attribute, which defines everything necessary for the CRUD operations inside data layer (mainly using reflation). And each of the Fetch, Insert, Update, and Delete DataPortal methods is typically brought down to a single line of code. While this approach is not suited for every situation (particularly, when loading a Collection with thousands of child objects), for the majority of situations it is quite elegant, fairly easy to debug and/or change when necessary, and is impervious to any major data-access paradigm changes on the part of Microsoft.

(@rockfordlhotka -- I would be happy to create a white paper on this (and other customizations I've made to CSLA) for peer-review. If, that is, you or others think it might be a good addition to CSLA. I know it has made our codebase much easier to manage.)

You noted the desire to upgrade your Web project to .NET Framework 4.8. I would recommend building it on .NET 6 (as an ASP.NET Core Web App). I tried the MVVM of ASP.NET years ago, but found it to be a pain to deal with. However, the Razor Pages way of doing things in .NET Core is the most similar (in my opinion) to how the old WebForms page structure set up. You have a mark-up page (which still allows for in-line code as-needed), and you have a code-behind file for all the necessary object interaction coding.

Again, this is coded against CLSA 5.3+, which has worked perfectly fine for our needs. While I have yet to fully go through and test CSLA 6+, the fact that this site is built on .NET 6 makes me think that the changes in CSLA will little or no impact on the site. We'll see...

I'm sure your mileage will vary, but I hope this helps.

[DMFullbrook]

That's great feedback - thank you.

[rockfordlhotka]

@tabaguley I'd be interested in seeing what you've done regarding data access. I've tried to not be overly opinionated with how to implement DAL code in the framework itself, perhaps to the point that some productivity concepts could be added to help folks.