I had used DryIoc and LightInject in most of my .Net Web API 2+ solutions. Using new architecture, I would prefer to use NServiceBus or MassTransit for my next ESB implementation. However, I could not find any useful code reference that could help me to do Implementation of the NServiceBus/MassTransit IContainer with DryIoc or LightInject. Other IoC is not an option for me as the requirement from my company is to choose only from both of the above mentioned. Greatly appreciate any help from the community.
Will this help? "If you have your own container that is not already supported by a NuGet package, you can create a plugin centering around the IContainer abstraction. Once this is created and registered, NServiceBus will use your custom container to look up its own dependencies."
Related
I'm new to Opendaylight and I'm currently trying to develop an app to get packet-in, analyse them and then dispatch them to other app.
Does the blueprint replace the need for creating an Activator class to register the component with the OSGi framework? Or do we still need the activator to instantiate and set the dependencies?
As far as I can tell, the blueprint already does that, am I correct?
Any help would be extremely appreciated!
Yes, Blueprint takes care of the OSGi registration and discovery for you, as long as you declare the appropriate elements in the Blueprint descriptor: <reference/> to find a service, <service/> to expose one. The Using Blueprint page on the ODL wiki covers Blueprint usage in some detail, including OSGi integration and MD-SAL integration.
In many cases, if you’re using the ODL parent POMs you can take advantage of Blueprint autowiring, using #Singleton and #Inject annotations instead of writing an XML file.
(You can ignore all the Config Sub-System sections, that’s deprecated.)
I'm searching for a well documented XACML3-Framework in the open source world. I tried AuthZForce and AT&T XACML. Both seems to have many features. The problem: to get them running, I have to read the source code or find test-classes. There are no examples or anything else, that helps to understand the functionality of the framework. I thought XACML is the future of authorization but at the bottom there is no real community.
Is there an XACML-alternative for ABAC-implementations or is there no other way and I must use RBAC with programmed constraints?
Regarding AuthzForce Core (Java library), you have a tutorial on the home page of the github project: Getting started; and an example of usage with a PEP in a real-world scenario. If you are missing info on something, feel free to contact us on our support mailing list. I also emphasize the fact that all Java classes have Javadoc and Javadoc artifacts are published on Maven Central with every release. You can download them manually or make sure your IDE is properly set up to automatically download them when you use Maven dependencies in your Java project.
WSO2 IS can help (opensource):
https://docs.wso2.com/display/IS510/XACML+Architecture
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
Policy handling can be done via web interface (Carbon).
I can't seem to find a good way to create separate Service Layer and Repository Layer assemblies while using ASP.NET Core applications. I am trying to do it with EntityFrameworkCore and Azure Storage. I have found a few workarounds where they use .Net Core apps as assemblies but it cause all kinds of other issues for me as well.
Any help would be greatly appreciated.
Setting up a multi layer Application.
A few things to keep in mind:
The power lays in abstraction, being able to easily replace layers.
A layer/Project has dependencies which can not have circular dependencies!
say your main project has Db models and controllers, and DataAccessLayer has the services. then the DataAccessLayer needs the models from the main project and the Controller needs the services from the DataAccessLayer and thus creating a circular dependency.
Project structure
A simple abstract setup can be:
DbModels project (containing only plain simple objects equal to database tables)
IDataAccess project contain all the interfaces of the DataAcess services. (needs dependency on DbModels)
DataAccessLayer project, implementation of IDataAccess. dependencies: IDataAccess & DbModels
Toplayer project: contains the webApi/controllers. Dependencies: IDataAccess,DbModels and an implementation of IDataAccess, in this case DataAccessLayer.
The DataAccessLayer will ofcourse need EntityFramework as a reference. Also the DatabaseContext should be in this project (and the database migrations).
Also make sure to use the DI/IOC container to register and resolve the services.
This will be your setup for a repository project.
what other problems you run into?
why a repository pattern:
Credits to microsoft
As you can see in this image. A repository pattern is made to being able to easily switch Database.
If you are never going to switch database or use unit tests on dataAccess layer, it't basically not worth it to implement a repository pattern. (too much work, vs the benefit)
I'm not sure what issue you're encountering, but here is a good multi-project starter solution for ASP.NET Core web applications, broken up into projects by responsibility:
Core (domain model, abstractions, services)
Infrastructure (implementation-specific classes)
UI (asp.net core mvc web project)
https://github.com/ardalis/cleanarchitecture
Does that help?
I have started working with Ninject for a website and setting up DI within a project.
I have noticed you register the binding dependencies within the app_start called ninjectWebCommon. When the project loads, do all dependencies get registered? For example if you have over 50 dependencies registered, will this cause resource issues? Or does each instance gets registered on page execution? If not, Is there a way to lazy bind the dependencies or is this unnecessary?
Is there a better way of accomplishing this even if using another IOC Container?
You should read about Register Resolve Release pattern. Basically registration process is quite simple, you tell the container which types to use for resolving abstractions. No objects are created in this process. DI container creates the instances when a request hits your application. They may be created only once or on every request, depending on the life cycle.
You do registrations like that for other containers as well and it really shouldent be a resource issue. However Ninject is a bit on the slow side. If you can choose as you like you might be better off with a DI container like SimpleInjector.
For a comparison i used a website with some benchmarks.
We've got WCF setup to use Windsor. Now I want to start writing some integration tests and I'm running into a problem. I found an article by Ayende http://ayende.com/Blog/archive/2007/06/12/WCF-Windsor-Integration.aspx but I can't find the WindsorServiceHost he mentions. I even went and looked around WcfIntegration in the object browser and no luck.
Does anyone have a more up to date sample or have a short code sample they can share?
You will not find it in standard Windsor installation. It is separate Facility (separate project) which hasn't been released yet but you can download source codes from their repository.