With Claude Do I Need CSLA?

[MarkOverstreet]

We have used CSLA for several projects over the last 15 years and now that our team is starting to use Claude more and more, there have been some discussions about why we are even using CSLA going forward. There is a good argument to made to just let Claude write most of the application and implement standard business rules using native C# and create any web api layer that is needed to support reading and writing to the database.

In the past, I thought CSLA offered alot of benefits but I'd like to hear what others think? Is there still a need to use a framework like CSLA when Claude can write apps using more standard approaches?

[hurcane]

My two cents as we are in the middle of transforming a large on-prem desktop/server WinForms app to SAAS with Blazor Server UI and an OData based API. For us, CSLA offers the greatest benefit for the business rules. Validation is straightforward. The Blazor UI and the OData Post controller that are managing the same underlying business object can reuse the business object with no duplication of the business rules.

The OData API and the UI need different code to translate the state of the business object to the appropriate response format. Blazor needs a validation component. An ODataError response is generated with a custom converter class. These are effectively different UIs, so this is expected.

Under WinForms, we pretty much used CSLA for everything. The project had more read-only classes that were used for inquiries, reports, and any other forms that needed to show read-only information. For our OData query endpoints, however, we are mapping them directly to the database via EF Core because it's what has the most built-in support.

I think CSLA is still useful for authorization-level security, which includes read-only classes. This is an area where we are making a compromise for the OData query endpoints. If the business requires authorization to read a specific property, that requirement is being coded separately for CSLA read only classes and the OData queries. Other OData endpoints, especially actions and functions, are relying on CSLA.

I'm sure others will have different perspectives, but this is how it benefits my team.

[rockfordlhotka]

I have thought about this quite a bit @MarkOverstreet. Over the past several months (from December), I have written almost no code by hand, co-creating nearly everything I've done by using Claude Code. It has been a mostly fantastic experience, and I've created more code than I have in many years thanks to the increased velocity of design, coding, and testing via AI automation.

During this time, I've created rockbot (https://rockbot.dev) entirely without CSLA. And I've created a TTRPG assistant app that manages interaction between a GM and players using a custom RPG gaming system (Threa) my friends and I have evolved over decades. That does use CSLA and Blazor.

I've created a whole bunch of other things too - mostly MCP servers, targeted AI agents, and a memory-sync tool so Claude Code's memories are consistent across the different workstations I use on a regular basis. None of them use CSLA - but also none of them have a user interface or really even much business logic in any traditional sense.

My current thinking, based on observations (especially around rockbot and Threa) is that claude will often default to creating code that is hard to maintain over time. It duplicates logic frequently - following many of the same anti-patterns a normal developer would follow. Numerous times now, I've had to pause work on rockbot to have it consolidate numerous repetitive call sites where it wrote (basically) the same code 8-12 times, then fixed a bug in one site and left the others broken - when all of them should have been routed through one implementation of that code.

This happens in Threa as well, but a little less often, because in that case it is using CSLA and understands that there's this built-in goal of code reuse. Not perfect, but better than rockbot.

One key thing about Threa and CSLA - I rely heavily on the csla-mcp server being plugged into Claude Code. Without that, CSLA is (in my experience) a pure negative, because LLMs have 28 years of CSLA history, and they often pick ancient patterns that are no longer optimal (or even valid). With the csla-mcp server online, they almost always (sadly not always) pick modern v10 patterns. With the updates to Claude Code's memory model, it improves by itself too, as I correct it - so it rarely makes a mistake anymore.

This is not a firm answer yes or no 😁

I am finding that (with the mcp server) there is still value in using CSLA because the rules in the mcp server continually reinforce the DRY principal to the agent and give it a pattern to follow to avoid code duplication - which helps.