I can see your point, but when you consider that many of the WinAPIs are designed to work as teams and some of them you have to call twice to get the actual size of the data before you can use the call to get the data my position is that if I have a dotNet class that is the sole user of an API call it should have the P/Invoke interface internally.
Obviously if it's an API call that will be used in multiple places it should be in a global NativeMethods static class.
I just had a thought - what if I create a private NativeMethods static class for this object? I'll have to give that a try this evening. That would have dual benefits - the API calls will be obvious when reading the class source and it keeps APIs that are specific to supporting that class in the class source code and not dependent on another source file.
FXCop didn't throw the CA1060 warning. Apparently it's just looking for the NativeMethods class anywhere. This satisfies both FXCop and OO Design. This private class forces the P/Invoke calls to be obvious and it allow the containing class to be understood by itself.
Too many arguments to 'Public Shared Sub Send(to As String, subject As String, body As String, [from As String = Nothing], [cc As String = Nothing], [filesToAttach As System.Collections.Generic.IEnumerable(Of String) = Nothing], [isBodyHtml As Boolean = True], [additionalHeaders As System.Collections.Generic.IEnumerable(Of String) = Nothing])'
I am working on the correct usage of IOCContainer(Autofac) in a project which has mulitple assemblies. I am not able to understand the nested dependency pattern correctly as well as what would be the best exception handling strategy in case of failed resolves.
The post is not concise, as I am afraid I cannot explain my confusion in a brief manner. So apologies..
I am trying to use the 'constructor injection pattern' instead of 'property' or 'method' injection. so a class which looked like this:
privatestaticreadonly IDependency = IOCContainer.Resolve<IDependency>();
is changed to something like this
Class Foo(IDependency dependency)
privatereadonly IDependency = dependency;
however after cleaning up the whole code with the constructor pattern, the code looks like this
public Foo(IDependency dependency)
this.dependency = dependency;
var bar = new Bar(this.dependency);
public Bar(IDependency dependency)
this.dependency = dependency;
Now if the dependency was not available (IOCContainer failed to resolve this dependency), Foo will pass that dependency around, without worrying about the failed resolved call..
I think that given this scenario, the property or method injection methods seem correct as all the classes are directly calling IOCContainer resolves and then they would have a way to check if the dependency was resolved or not directly from the IOCContainer.
However A null check or a try catch can be applied when we access the dependency anyways even with the constructor injection pattern, for e.g.
(dependency != null ? dependency.doSomething : thrownew Exception(DependencyNotAvailable);
Is it correct approach? How should I handle the exceptions from IOCContainer otherwise?
I see some things in your code which I would change, and this should hopefully clear things up for you. Basically, you're mixing up IoC with newing stuff. If I were you, I would change the implementations to something like this:
As you can see, we're relying on injecting any dependencies here (i.e. injecting IBar rather than newing up Bar), and we test in the constructor for nulls. That way, we determine early on whether or not an actual implementation has been passed in.
PrivateSub cmbcustomer_SelectedIndexChanged(sender As System.Object, e As System.EventArgs) Handles cmbcustomer.SelectedIndexChanged
txtticketnumber.Text = "9" + Format(cmbcustomer.SelectedValue, "0000")
Catch ex As Exception