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.
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 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'm developing an app with IBM MobileFirst Platform and I find an issue with Worklight.js file. Worklight.js is extending Function prototype defining several methods like bind, curry, wrap and so on.
My app is built with aurelia framework an after upgrading the framework to the last version I'm facing a funky issue related to bind extension.
If I comment the bind extension in worklight.js everything seems to work like a charm (don't know why worklight implements its bind version).
Worklight.js file seems to be added to the wlapp package at build time. Is there a way I can override this file so I do not have to modify .wlapp file each time app is built?
Thanks
The direct answer to the specific question you've asked is, no, there is no way provided to override worklight.js. This is the core JavaScript code needed for the MobileFirst Platform client-side to function, and as such the user isn't given any means to modify it - it's injected into your app (i.e., into the WLAPP file) during the build process.
I'm not aware of any specific issues with Aurelia, but have certainly seen cases in the past where an app that uses two different frameworks (e.g., MobileFirst Platform / Worklight, and something else) "fight" with each other because they both want to implement extensions that are not compatible with each other - in which case, one framework or the other usually needs to change to accommodate the other.
If you are a customer with paid support, I'd suggest opening a PMR so we can get our developers to take a look at the issue.
I have the same problem with Angular. Worklight bind makes Angular controller fail to instantiate. The solution is to recover the bind function after worklight is loaded.
var bind = Function.prototype.bind;
window.wlCommonInit = function() {
Function.prototype.bind = bind;
};
I recently started refactoring my site resulting in the following situation. I have a separate project containing all the surface controllers, views etc for the frontend users. In this project there is also StartupEventHandler wich registers the interfaces, controllers etc using AutoFac. I started a second project file containing the controllers, etc for the backend users. This project also uses AutoFac in the startupeventhandler and registers practically the same iterfaces as both front end en backend share the same services amongst them.
Now when I start the site, the frontend looks good. But when going via the umbraco backend the views dont get rendered with an error "Parameterless constructors not found". When I rebuild and restart, the backend page gets rendered without errors, but now the frontend pages give me the same error. Until I restart the site.
My guess I has to do with AutoFac and two startup handlers. The handlers each reside in their own assembly and namespace ...web.client and ...web.admin.
Anyone any clue on how to resolve this. I dont think it has to do with Umbraco as there are plenty of plugins which probably have also their own startup handlers.
I think I have found a proper solution. As I told in my question I had a separate project productname.customername.web.client and productname.customername.web.admin. What I have done is taking all the start up event logic out of those projects, created a new project productname.customername.web and put in there. From there I added a reference to both client and admin project and registered the controllers. It works fine now.
I have an application that hosts several WCF services. I have created a custom ServiceAuthorizationManager that is working perfectly. I inspect a few elements on the OperationContext.IncomingMessageHeaders to get a username and password. This was to overcome some limitations in our environment that wouldnt allow us to use what was built into the platform. the manager creates a custom IPrincpal, with a few necessary custom objects in it, and places it on the currently running thread, for use later in the WCF business logic. this is Working great.
Problem is that I have a WCF service that is a workflow, and I need to use the same mechanism there. The Manager is being called correctly, however when executing the Thread's currentPrincpal isn't my custom principal, it's a genericprincipal. Investigation shows that the workflow runtime is creating a thread, and not using the thread that the WCF call came in on.
Has anyone run into this issue, and are there any good solutions to it?
If the runtime is in the same appdomain as the manager then you should be able to call
AppDomain.CurrentDomain.SetThreadPrincipal
See here for more information