-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
U4-11427 : Remove property injection #2690
U4-11427 : Remove property injection #2690
Conversation
…ed) gets dependencies injected through ContainerUmbracoModule.
Notes on the UmbracoModule. Need to abstract resolving via Current.Container to remove LightInject refs.
More notes / fixme.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple comments but the gist is that the removal of property injection should also mean there are no setters for those properties since they are set only in the ctor. I think any fixme remove
ctor's for our built in controllers should be removed indeed. And for the empty protected ctor's, don't we want to call base or this and populate the dependencies based on Current
?
I know this is a WIP so things are in flux :) looks great so far!
@@ -36,37 +35,31 @@ public abstract class PluginController : Controller, IDiscoverable | |||
/// <summary> | |||
/// Gets or sets the Umbraco context. | |||
/// </summary> | |||
[Inject] | |||
public virtual UmbracoContext UmbracoContext { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should not have setters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Missed it.
@@ -10,5 +16,13 @@ | |||
[UmbracoAuthorize] | |||
[DisableBrowserCache] | |||
public abstract class UmbracoAuthorizedController : UmbracoController | |||
{ } | |||
{ | |||
protected UmbracoAuthorizedController() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we want to call : base(....)
and use Current
to populate the dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will automagically call the one in UmbracoController. 😋
\o/ I manage to squeeze in an hour here and there. |
…factory method that looks up services by name instead.
src/Umbraco.Core/IO/FileSystems.cs
Outdated
@@ -305,7 +305,8 @@ public TFileSystem GetFileSystemProvider<TFileSystem>(Func<IFileSystem> fallback | |||
|
|||
// fixme - switch to using container. where are these registered? | |||
|
|||
var fs = (IFileSystem) Activator.CreateInstance(typeof(TFileSystem), shadowWrapper); | |||
//var fs = (IFileSystem) Activator.CreateInstance(typeof(TFileSystem), shadowWrapper); | |||
var fs = Current.Container.GetInstance<TFileSystem>((IFileSystem)shadowWrapper); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Shazwazza seems like you've done something like this before: seesharper/LightInject#237
Got any idea why it complains it can't resolve the dependency? We get this down, we've basically got all tight couplings solved.
See ContainerAdapter.cs line 48 for concrete impl. Basic forwarding of object array to concrete container. (No extension usage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm, got the hang of it.
A bit messy, and probably leaves quite a bit of dead / useless code around that should be deleted. Needs some manual testing.
…for most regression runs.
@@ -44,6 +44,9 @@ public override void Compose(Composition composition) | |||
composition.Container.Register<DatabaseBuilder>(); | |||
|
|||
// register filesystems | |||
|
|||
composition.Container.Register<IFileSystem, MediaFileSystem>((f, wrappedFileSystem) => new MediaFileSystem(wrappedFileSystem, f.GetInstance<IContentSection>(), f.GetInstance<ILogger>())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is most likely not covered by any tests. :/
Should look into testing/verifying all composition builders etc. later.
Getting there. The MediaFileSystem should now be resolved from the container, but get the ShadowWrapper thingy as a runtime argument. A few concrete IO tests fail, most likely due to less stubbed dependency needs. Otherwise, just MembershipHelper to go. :) Also took the liberty of adding a "Slow" category to a bunch of integrated tests. Makes it quicker to run "most". (8 vs 16 min on my older box) |
…pletely Broken (tm). Need to review whole lifetime & registration of it.
(But OMG! there's nearly no test coverage of Umbraco.Web :O )
Boom! Done! At least I hope so. Seems like all the tests are passing, but the Umbraco.Web assembly is sadly lacking in coverage. Guess the MembershipHelper dependencies has to be tested somewhat manually sooner or later. There's so much more to do, but at least the first task can be ticked off. :) I'd really like to get on with abstracting all the registrations as well. Should I make it another PR based off this? Could probably rebase and force push the first one. |
@lars-erik I may not understand all of this PR, but seriously, great job 👍 |
Going to review all this asap. Excellent! |
\o/ It's interesting to notice the faintly fresher smells of the now huge constructors and weird registration cases. They probably reek a bit of feature envy and possibly SRP breaches (and more). I guess it's worth investigating when through the immediate bits. On a sidenote - some of the scope and IO tests seem to be failing intermittently. Dunno if that's from these changes or if it's still a bit unstable? |
FWIW some merge conflicts need to be fixed - have done it locally - now going to test and review code |
…Non LI req. / MS-DI)
…yinjection' into temp8-di2690
Yay! |
(Full discussion on tracker under ID from this PR's title)
(see original issue)
HttpModules able to get injection for now. Will continue to see about controllers etc.