To Use Dependency Injection…Or NOT!

[tabaguley]

I have been reading through numerous posts, both within the CSLA group here, as well as other non-CSLA groups/posts on the Web. At this point in time, there is a critical question I cannot answer: What problem does Dependency Injection actually solve??

Apparently, I am not alone in posing this question. Clearly, there are many proponents of its use. But all I see is a nightmare of unnecessary and excessive parameters, interfaces, objects being passed around, etc. …just to “fix” something that wasn’t broken with a new-fangled way of doing things.

Now, I am faced with a critical dilemma: how do I stay current with the CSLA Framework?

Because with dozens of applications built over the years, containing thousands of CSLA-based business objects, and hundreds of thousands of lines of code, there is NO WAY to implement CLSA 6+ without breaking EVERYTHING (and forcing a radical re-write of the entire code base).

Here are a few of the key features that attracted me to CSLA over 20 years ago (yes, I was there at the beginning of CLSA .NET in 2002):
• Object In Charge – Private Constructors; Public Shared/Static Get_() and New_() methods to create or load objects
• Clearly and uniformly defined DataPortal_ Methods
• The ability to use a DataPortal Server (via Configuration) if desired (but not required)

That last bullet point is key to my next question: CSLA did not demand you use a DataPortal Server – you could set one up and use it if desired. Your code would work the same with or without it.

(Even other CSLA features like automatic n-Level Undo may be disabled when not desired: DisableIEditableObject = True)

So my next question: Can CSLA be updated to allow for Dependency Injection if desired (via config settings), but still allow for use of the DataPortal the way it always has been? [One could say, “The way God intended;” but that might be blasphemous.]

Not only would this allow users of CSLA to upgrade without breaking things, but it would also allow the same CLSA codebase to be used in both older (say, WinForms) applications, as well as the new hotrod UIs (like Blazor) – without breaking things or requiring a departure from the norm in how the UI platform is typically used.

(Yes, I’ve reviewed the latest WinForms example for CSLA, and all I can say is, “That is not at all how a WinForms application should be built or function. Just because it can be made to work like an SPA or WPF application does not mean it should be.)

And BTW… My latest Website, running on .NET 7 (and .NET 5 & 6 before that) works perfectly fine using CLSA 5+! Dependency Injection is totally unnecessary for CLSA, even though the site itself uses it.

SO… Is it possible to make Dependency Injection optional? Or must we continue to maintain and use an older, working version of CLSA (5+) if we want to avoid the headache of trying to upgrade?

(I'm also going to post a Poll asking about this, as I'm curious what approach seems best to the community as a whole.)

[kcabral817]

The use of the dataportal is pretty close to what it was, except that it is no longer a static method. You will inject the object into the class. You are also able to create a new object using a factory class that is also injected but usable for creation of new objects. Dependency injection is not optional any more as critical functionality expects authenticated users and there is no way to create a new object using the static methods. I just did a major upgrade of CSLA, .NET 7, and EF 7 and converted my WPF application to Blazor. It's a major undertaking but I am able to stay current with new functionality on the horizon that CSLA 6 will implement. As you know, EF 6 to Core was a major "migration" technically but in truth a rewrite. But without upgrading it would be a nightmare using MS's old technologies. Rocky and Cakemonster can provide way more technical detail and overarching reasons for the CSLA paradigm shift.

[kcabral817]

I switched to Linq from stored procedures as it was just an easier way with EF 4, for me at least. Although I used stored procedures, I like the syntax of linq and the ease of use. I am under the (false) impression that I could switch out my database for different one, say sqllight, and preserve the linq queries. I let EF contend with the low level stuff and let them performance tune too (given the correct indexes are applied and normal dba functions are performed).

[TheCakeMonster]

I have fairly grave reservations about EF, and ORMs in general. I learned about ORMs a long time ago by going to a number of community events, but when carefully took stock of the audiences in the rooms, there were no DBAs or security experts present. I thought that was both interesting and concerning.

The growth of ORMs seems to be based on a desire by developers to avoid learning SQL - and that's an issue. I consider this a fallacy on which ORMs stand. You should never avoid learning how your database functions, or you will end up writing systems that perform absolutely fine with a small amount of data, only to fail when the data volumes grow. Optimising set-based operations is important and will continue to be so for many years to come - and that requires detailed knowledge of SQL and relational DBMSes (as well as NoSQL offerings).

The security of data stores is pretty awful these days, and that is one reason why there are so many data breaches from IT systems. People who use EF tend to allow migrations to run at startup, meaning they require the account through which they access the database have full permissions on the whole data store, including being able to modify the schema. That's a truly awful practice from a security standpoint, and one I will continue to rile against. Defence in depth is a fundamental security tenet, and one we ignore at our peril.

Yes, I too prefer SPs, because they encourage (or at least do not discourage) better security. I have also found systems built with SPs are much easier to diagnose perf issues, because a SQL expert can look at the SPs and their execution plans without needing the code to run against the database. A DBA doesn't know how to run your system, but they do know how to run a stored procedure, so they can much more easily trigger perf issues and resolve them on their own, while you work on something else.

Having said all of that, I do like that EF generally stops people trying to submit dynamic SQL to the database - dynamic SQL created through string concatenation, without parameterisation. Hand-written dynamic SQL is a truly awful risk - it is so easy to introduce a SQL injection vulnerability when working this way - that I'm not totally against EF/ORMs. If people really are going to learn the absolute minimum about a database, then I'd prefer they accessed it via an ORM than directly.

Oh, and I should say one more thing - I'm currently using EF at work. It's what my new employer uses, and that's pretty common throughout the industry. I'm not one for throwing away systems just because they are based on decisions I would not have made. For that reason I get my head down and try to encourage best practices with it. As it happens, I'm not sorry to be avoiding SQL, because they also use PostgreSQL, and the SQL syntax for that is not very dev-friendly!

[Chicagoan2016]

The security of data stores is pretty awful these days, and that is one reason why there are so many data breaches from IT systems. People who use EF tend to allow migrations to run at startup, meaning they require the account through which they access the database have full permissions on the whole data store, including being able to modify the schema. That's a truly awful practice from a security standpoint, and one I will continue to rile against. Defence in depth is a fundamental security tenet, and one we ignore at our peril.

@TheCakeMonster
what kind of permissions do you give to the user in 'configuration' file? The user your code uses to access the database.

Thank you

[TheCakeMonster]

@Chicagoan2016 The minimum possible.

When using stored procedures in MSSQL I grant execute permissions on the stored procedures necessary for each application to a role, and then make the user in the connection string a member of that role.

When using EF (or any ORM) you need to grant rights directly on the tables used by the application, and that's why it is a bit less satisfactory.

Wherever possible I want to create a separate application that uses a different set of credentials with the additional rights necessary to run migrations, and execute that as part of the deployment process.

I hope that answers the question?

[Chicagoan2016]

@TheCakeMonster yes, appreciate your response.

[Chicagoan2016]

@tabaguley I enjoyed your post and I am in a similar situation, not just because of dependency injection but other reasons as well. Almost all of our projects are currently in Csla 4.xx and I don't see migrating them to Csla 6.xx (or latest version) anytime soon. Our team is ridiculously small and only new projects could 'afford' to direct the latest versions of Csla.
Speaking of latest versions of Csla, I have noticed this thread is getting quiet which scares me because my career is dependent on Csla (I am not kidding).
Regards

[rockfordlhotka]

@TheCakeMonster has some good insight on current/modern code generation.

[TheCakeMonster]

I may know a team who created a design and code generation system. ;-)

https://getdesigning.dotnotstandard.com/

[Chicagoan2016]

@TheCakeMonster I have tried to follow your video tutorials and here are some suggestions. I promise I mean no disrespect and will gladly (and promptly) delete this post if you find it offensive in any way.

Some of the terms in the tutorials are used in a different context (than here in the US or may be it's just me 😊).

I couldn't follow the terms 'System' and 'Design' in DesiGen and how do they relate to Solutions and projects in Visual Studio?
In American schools, 'Data Structures' is mostly used (incorrectly?) for arrays, linkedlists, stack etc.

Could we generate code for (Csla) business objects based on stored procs? would love to see properties, DTOs and data access code generated by Desigen.

We had used CodeSmith in the past but the templates there are no longer updated.

Kind regards

[TheCakeMonster]

@Chicagoan2016 Absolutely no offence taken, and I appreciate your feedback. I'd never take offence at a reasoned argument, request for information or desire for clarification.

I'd best be brief, as I don't want to pollute Rocky's CSLA discussion with a somewhat off-topic discussion. There is an alternative place for more detailed discussions about DesiGen, so if it's helpful to continue this then create a discussion at https://github.com/DotNotStandard/DesiGen-Community

In short, naming is hard. Ever was it thus. In creating DesiGen I've tried to choose words that mean something, but which don't force people's thinking to be too constricted. But I agree that names mean different things to different people. That is forever a problem - perhaps the biggest problem of all in software development. People's interpretation of words depends upon their frame of reference - their culture, their prior experience and so on.

I'll try to give a quick bit of clarification, with a keen eye on trying to avoid hijacking this thread!

System is optional. It's a way to have multiple totally different coding conventions, if that is helpful. Use it only when you need that. I architected multiple systems at my last company, each of which were made of multiple solutions. We used Windows services in a vaguely microservices-like approach (before that was a buzzword) where there were background operations to be performed, usually interacting with remote third party systems. However, we had several main systems, all totally unrelated. One was new and written in C#; one was somewhat older and written in VB.NET using different naming conventions and for a totally different part of the business, and a third was in 'Classic' ASP using a third set of coding conventions. That's all System is about; a collection of one or more solutions that are related in their collective functionality and - most importantly - all use the same coding conventions.

Design is the process of thinking before doing development. It is the conversion of a task/requirement in a task management system - Jira, Mantis or whatever - into an idea of how to solve a problem for a specific, small requirement.

The result of a successful design is the start of the development process. This involves creating, or most often adding to, one or more projects in a (usually just one, but maybe more than one) Visual Studio solution - at least that's the case when working with C#.

In other words, a design is the collection of changes that we intend to make to a Visual Studio solution, and the projects it contains. Solutions and projects are mentioned in - and could be created from - a design.

As it happens, C# and Visual Studio form a subset of what DesiGen can do - it's not restricted to just C# and .NET. It could theoretically be used for Java, or Rust, or Go, or whatever. But I digress.

Data structure is somewhat as you have described it, but at the theoretical level. It's intentionally left slightly abstract. It is the definition of a collection of bits of information that you want to relate together in a 'thing', such as in a table, or an object, or both. I avoided the word table as that makes people think it can only be used for storage, which is not the case. Need to generate an object with a bunch of properties? Create a data structure, with a field per property. Need a table, or a stored procedure to access a table - create a data structure for those. Often, a data structure can be used for defining all of these at once - and that's where the power of the approach lies, IMO.

A data structure could also be called a data definition, or a model - except that doing so might risk restricting people's thinking to an RDBMS or ASP.NET MVC. A data structure is theoretical, and exists at the design stage, as a step towards creating something concrete of a predefined shape when we generate.

CodeSmith was a great tool, but it only generated a single file at a time, so using it was a bit repetitive. Use it once to generate a CSLA object. Then again to generate a DTO object. Then again to generate the SQL which you run to create a table in your database. Then again to generate the SQL that is a set of stored procedure definitions. Then again to generate a a ViewModel. Then again for the View in the UI.

As it happens, the old, free version of CodeSmith was also running on .NET Framework 2.0, which is getting a little aged, and that had tripped me up a bit, so I wondered what might come next.

DesiGen takes what CodeSmith did a stage further by offering to generate multiple files at once. These are often multiple layers in an architecture that represent the same set of bits of data in different layers. All off a single definition - a data structure - defined once, as part of the design process. Generate the CSLA object, and the stored procedures, and the SQL that can be used to create a table, and the ViewModel, and the View, and the DTO, and the repository that contains all of the data access code, all in a single click of the 'Generate' button.

As for generating from a stored procedure, that's sort of the opposite of what I really intend. My proposal is that we approach the development for a small task in a few steps:

1. Think first, in a design, without actually creating any real code. This is all done in DesiGen (and as the videos show, is quite quick).
2. Validate that design by getting other people's thoughts in some interaction, such as a discussion, whiteboarding session, design review, email chain, whatever.
3. Revise the design based on feedback, again in DesiGen.
4. When (and only when) the approach has been discussed, refined and is considered worthy of development, then generate a whole lot of code in all of the languages necessary (C#, SQL, Razor, CSS, JavaScript, markdown, Java - whatever) based on the thinking done to date.
5. Customise the generated code to complete the delivery for fulfilling the requirement. This includes all of the nuance that can't be code generated (such as validation rules, UI tweaks, authorisation etc etc.) This is the development bit we are most used to.

I think the discussion on which comes first - stored procedures or design - is somewhat similar to that of deciding on the code-first or database-first approaches when using an ORM, such as EF. I could create a system which encourages you to create a table or stored procedure and use that as the model from which to generate. That is indeed what CodeSmith did. However, following this process requires you to create a table that might be amended or totally replaced based on discussion/review/feedback. If that were to happen then you would have done development that might be time wasted.

DesiGen follows a different path. It is based on a slightly different workflow: design-first. Perhaps we should create something that is entirely separate from the codebase, and very quick to create. Call this a suggestion, or proposal. It's the electronic equivalent of what comes from a whiteboarding session. You might even call it a design. Then we generate from that.

Think, validate, generate.

[mtavares628]

@mar72vin I have been updating CSLAGenFork to CSLA 6. I have a project that I'm converting that had a large number of objects generated from it, so it made sense for me to update CSLAGenFork instead of restarting from scratch. The fork for my updated version is at https://github.com/mtavares628/CslaGenFork

I should note though, that I only focused on the stereotypes for my project, like EditableRoot, EditableChild, ReadOnlyCollection, ReadOnlyChild, etc. I also continued to use static factory methods within the object (just passing in a choice of AppContext, DataPortalFactory, or typed DataPortal parameters) rather than creating separate factory classes for each object.

@rockfordlhotka I did just submit a pull request for this in your fork if you are ok with the caveats above.

[rockfordlhotka]

We really had no choice but to embrace DI thanks to Blazor. It literally doesn't work without DI.

In CSLA 5 I tried to support DI without requiring it, which became a blocker for Blazor very quickly. So CSLA 6 requires DI so it can fulfill the core promise of providing a consistently way to build your business logic regardless of your UI or DAL technology choices.

At the time it was clear that this would cause some pain, yet there's no way around it. Truly using DI is very much like truly using async/await or generics - you either go all the way or create a mess that would make no one happy in the long run.

Hopefully you have found and read the upgrading to CSLA 6 doc? There are some good ways to minimize code changes for existing codebases. Yes, you'll need to update your code, but the updates can be rote and mechanical if you want to take a minimal approach for older UI technologies.

If and when you go to Blazor you'll need to make slightly deeper changes, because (again) Blazor is built around DI.

In the long run I suspect most folks building .NET UIs will end up using Blazor. Sure, Windows Forms and WPF will remain basically unchanged for (probably) decades, but it'll get hard to find people willing to use those technologies. MAUI might succeed, but I'm personally finding that when I use MAUI it is via the Blazor Hybrid model, so I'm really building the UI in Blazor. There's no doubt that server-side aspnetcore MVC and Razor Pages will remain important, though honestly they also work better with DI than without.

If you've been watching the evolution of Blazor for .NET 8, the Unified Blazor ideas that are being floated may make it so we can write server-side code using the Blazor UI model, and then auto-switch to full Blazor once the runtime loads in the browser - some pretty interesting stuff for sure!

I guess that's the centerpiece of what I'm saying - if you continue to use legacy UI technologies you can use relatively low-impact techniques to switch to "using DI" without really using DI very much. In the long run though, I think the pressure will continue to mount for organizations to modernize to newer UI technologies, where DI becomes required.

(fwiw, you can also use DI in WinForms and WPF; doing so (imo) simplifies or eliminates a lot of UI framework code that we all used to have to write by hand or bring in via a UI framework dependency (MVVM, etc.); I know that's not helpful for existing codebases, but I can say for sure that if I started a greenfield WPF app today I'd use the DI approach to simplify so many things!)

[TheCakeMonster]

I personally find DI to be a very useful tool. In my experience good use of DI makes systems much easier to modify - to develop and enhance over time. Gone are the days when you had to change multiple classes to add a new dependency to a lower tier in your application; add it to the constructor of an injected class and it's available where you need it, with minimal effort. It's this nested dependency resolution that is so useful. ClassA uses ClassB uses ClassC, and you need to add a new dependency to ClassC - and it's easy to do by adding it to the constructor of ClassC if ClassA is retrieved from DI. That's a great benefit.

DI-based systems are also easier to unit test, in general. I'm not a believer in TDD, but I do believe in the benefits of unit tests. It is possible to build testable systems without DI, but it is quite a lot more difficult.

To some extent, I think of it less being about DI and more being about pluggable architectures.

I'd say two things with regards your dilemma about using it:

1. Embrace the benefits. It's not just a change for change's sake. Many things in the industry are just that - minimal APIs anyone? sigh - but DI is definitely not. DI offers great benefits in new systems.
2. There is no requirement to upgrade CSLA whenever there is a new version. You chose CSLA to solve the problems you had at the time you started the solution, and those problems (or the way you address them) probably haven't changed in the meantime. There may come a time where you have to upgrade because the old version stops working on the latest version of .NET, but you don't have to do it until that point.

There is a counter argument to point 2 of course - keeping up to date a bit at a time is sometimes easier than a big bang later on. However, I totally feel your pain at this point; the upgrade to CSLA 6 is a big bang in itself, so I'd delay it until you feel more ready for it. That time may come, or it may not, but at the moment you are not in the right mindset to undertake it because you don't appreciate the benefits - and that's totally fine. That's a reasonable decision. The one recommendation I would make is that you try to remain open to changing your mind on that decision in the future.

What I have done in the past is kept somewhat abreast of new versions of CSLA, but only upgraded when I felt the benefits outweighed the costs. Upgrades have been rare; many of my systems have kept on trucking for many years (decades) on the version of the framework we started out with. DesiGen hasn't been upgraded to CSLA 6 yet, for example - but it's still working fine at the moment on the older version on which it is based.

I have to admit the length of time we can stick on older version might be more problematic in the .NET Core/5/6/7 world (as opposed to .NET Framework). Annual releases of the runtime might make backwards compatibility more problematic, we'll have to wait and see.

[rockfordlhotka]

The one thing with option 2 - not updating - is that I (at least) can only afford to focus on maintaining and enhancing whatever version of CSLA is current.

CSLA is open-source of course, and I'm happy to accept PRs that back-port more recent enhancements back into previous versions (within reason, as I still need to be able to build and package that previous version, so I can't go back too far with the tooling I have installed). And people have done this - back-ported specific features that they really needed in whatever version of CSLA they were using. Sometimes they did it in their own fork, other times they've contributed back into the main codebase to benefit everyone 🎉.

As @TheCakeMonster says though, if you are productive and happy on the version you are using, and you don't plan to leverage major new features of .NET (like Blazor or MAUI or cloud-native) then there's a good argument for staying where you are.

My thought though, is that this is probably a risky move long-term, because not remaining at least reasonably current means accumulation of technical debt. The odds of someone eventually pressuring your code to work with the cloud, or have a more modern cross-platform UI are quite high.

[rockfordlhotka]

And by "cloud" I don't necessarily even mean a public cloud. As the container world matures it is becoming more realistic to run your own container orchestration system in your own data center (though I'd say we aren't there yet for most orgs). Not that this is a miracle cure for all problems, but if your problem is inefficient use of your servers then container orchestrators can be a solution (assuming your code is cloud-native or at least cloud-capable).

[TheCakeMonster]

Oh yes, I totally agree. I wasn't saying that old versions would be actively be maintained, only that they are not actively deprecated either.

Having new features is almost always going to require upgrades. But by and large you can choose whether you want to stay current or not. You pays your money and takes your choice. Or don't pay, as it happens. ;-)

[swegele]

Man do I feel your pain @tabaguley. There's no easy way around it. I am not kidding when I tell you I had the EXACT same frustrations you described. ~1000 business objects to convert and somewhat new to DI and wondering why the hell I needed it anyway.

Luckily I had about 80-85% code coverage via an automated business layer test suite so after the conversion to CSLA 6 I had good confidence that all was working if they passed.

Anyway, I agree with the advice given. Despite the pain, it is worth it. Upgrade when you need, delay for a while OK, but watch for tech debt and don't get too far behind.

Most of my time was spent learning new patterns and playing in a small test project with different ways to get it done. Obviously, the main issue was how to deal with ApplicationContext no longer being static and public! Ugh. So I spent a few weeks learning and experimenting before the big plunge. The actual conversion took a few days of my time to slog through all the .cs files.

Like Rocky said, it was mostly rote cut/copy/paste over and over and over while my eyes turned red and I tried to remember to blink every now and then.

In the end, other than being madly in love with Blazor SS, I feel the greatest benefit is just being in .NET 6+ and all that brings. The new project format for Visual Studio and the way it properly handles Nuget packages and transient dependencies is just so much cleaner. Take one look at the new .proj file vs the old and you will say "gee where'd all that old confusing crap go!?" The number of your nuget packages in project dependencies will be clean and much smaller and easily identified in a hierarchical format.

Anyway, good luck and as Nike used to say "Just Do It" :-)