I'm trying to figure out how best to implement extension methods that register services when users of my library may want to override some of the default implementations of various interfaces. It seems like there are 2 ways of doing things.
The first way is to use services.TryAdd inside the extension method, which would enable you to register the override implementation by using services.Add before calling the main extension method so that your implementation gets there first. This works because .TryAdd won't add if there is already something registered for the interface.
If the extension method uses plain old services.Add instead of .TryAdd then you can still override the implementation but now you have to register your implementation after calling the main extension method that adds the default implementation.
To me it seems the first approach is the better one. If you call services.Add more than once with a different implementation of the interface then they both do get registered and you could actually take a dependency on an IEnumerable of the interface to get all of them. But if you really only need one implementation in the app then it seems better not to have any extra implementations in the collection. Obviously if the app does use multiple implementations of the interface then you would want to add all the ones you need.
I wonder if there is a consensus about this or a recommendation or is it just up to individual taste.
Related
In my project I have the interface IProcess and a lot of classes implementing this interface. I need to register all those implementations. The following code is working fine for me:
Container.Register(Component.For<IProcess>().Named("SampleProcess").ImplementedBy<SampleProcess>());
Container.Register(Component.For<IProcess>().Named("SampleProcess2").ImplementedBy<SampleProcess2>());
However using this approach for registering is tedious if I have a lot of implementations. Therefore I am looking for a registration method to register all implementations of IProcess in a given assembly by name. The name that should be used for the registration key is just the class name.
Can someone pls give me a hint where to look for?
Sounds like a classic scenario for the convention registration API.
container.Register(
Classes.FromThisAssembly()
.BasedOn<IProcess>()
.WithServiceBase()
// and then if you *really* need to explicitly control naming
.Configure(c => c.Named(c.Implementation.Name)
)
Generally explicitly naming your components shouldn't be used, unless you have multiple components with the same implementation class, so just make sure you really need it.
I'm currently trying to implement VIPER-architecture in my project, and there is some questions I encountered with.
I have two modules in my app, that have some similar functionality (they both have imagePicker and ability to upload media to server, that implemented absolutely the same for both screens).
My question is how could I reuse this similar functionality in both modules? Trouble is that my imagePicker has many methods declared in Interactor that handle different events while selecting and uploading image (such as didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() and so on).
Should I create third module with this functionality and then somehow subclass my other modules from it? Or maybe there is a better way of doing it?
The only similar components/methods I'd use are Data Managers, which can be shared between as many Interactors are you want, and yet being 100% compliant with VIPER architecture.
So, a DataManager called, for example, MediaApiDataManager() would be responsible for the implementation of the core code to UploadMediaFile() etc
I suggest you read this post for more great tips on VIPER: https://www.ckl.io/blog/best-practices-viper-architecture/
I think you need create abstract class and implement inside imagePicker logic. Declare interface (protocol) for it class with didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() methods, implement this methods in class and inject to your VIPER modules
For the two modules try to abstract the similarities and try to build a Class of it. If both classes differs on the data type use Generics, also you can use Protocols, so declare the common methods of the two modules in one protocol and implement each one of them as an extension.
Maybe this tutorial helps. https://medium.com/#richiemon/protocol-extension-dispatching-6d5229f1338e
If I create a subclass of one of Apple's classes, ie: UIViewController, it comes with some methods already defined in the implementation file, ie: -viewDidLoad.
Is there a way to do this with my own classes?
I have been searching for the answer but haven't come up with anything.
Edit: To clarify my Question
I know how to subclass & use protocols etc.
What I want to do is have important methods that should be overridden by a subclass written into the implementation file automatically.
Better example:
If you subclass UITableViewController you will need to implement
-numberOfSections...
-numberOfRows...
-cellForRowAtIndex...
But you don't have to write them yourself, Apple automatically adds them into the file.
So is there something in obj-c that allows me to do that with my classes or is that something Apple has baked into xcode that can only be done by them?
These are basically boiler plate code which is written when the IDE is being designed itself.
I have an Castle Windsor interceptor that I want to use for two different interfaces (just call them IOne and ITwo). Similar to this post http://thatextramile.be/blog/2009/07/protecting-your-application-from-remote-problems/ I want the interceptor to be a singleton with respect to the same interface, but be a different instance for each interface. Obviously registering the interceptor as singleton causes the same instance to be reused across all instances of IOne and ITwo. I need the interceptors to behave this way because I need them to preserve state for all calls through that interface, but they need to be distinct from each other.
I've come across lots of possible ways to approach this, but since I'm not an expert on Windsor, what is the preferred way to handle this situation?
Documentation says it's recommended to use the interceptors with transient lifecycle.
Make interceptors transient
It is strongly advised that you always make your interceptors
transient. Since interceptors can intercept multiple components with
various lifestyles it's best if their own lifespan is no longer than
the component they intercept. So unless you have a very good reason
not to, always make them transient.
I suggest refactoring the shared data interaction to another interface then use that as singleton.
An alternative approach is to make the interceptor generic. Then you can specify the interceptor with the generic argument of your interface.
public class MyInterceptor<T> : IInterceptor
{
...
}
Then register like this
container.Register(Component.For<IOne>()
.ImplementedBy<OneImplementation>()
.Interceptors<MyInterceptor<IOne>>());
container.Register(Component.For<ITwo>()
.ImplementedBy<TwoImplementation>()
.Interceptors<MyInterceptor<ITwo>>());
.Net will recognize MyInterceptor<IOne> and MyInterceptor<ITwo> as separate classes, and so Windsor will create different singleton instances for them.
Of course, this only works if you're making the interceptor. If it's in some library that you don't have access to, then your out of luck with this approach.
Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
#Stateless
#RolesAllowed("javaee")
public class HelloEJB implements Hello {
#PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager OnExecute method; I pretend to use the TAction.Name property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.