I have a .Net solution with two projects. The first project it's a MVC4 application and the second one it's a ClassLibrary project.
I can access to the classes of my MVC4 Projet to my ClassLibrary (like models), but I can't access from my to my ClassLibrary to my MVC4 project to inject a dependency or create an instance.
I'm missing some reference?
Writing a class Library that will be used by an MVC project should be mostly self sufficient, (having dependencies on other libraries etc) but the Library really shouldn't need to know anything about the MVC project. If that is what you are trying to do, you need to do some redesigning. Models and other things should be not be a part of the MVC project adding them to the class library would be a better design.
There is no need to other Classlibrary. You can use all those features in the Model.
You can use any dependincy patterns in model like NUnity, Ninject etc. but EntityFramework is always offers Repository pattern as a dipendincy injection with IOC.
If you want to use instate of all you can create a sub project and refference it to the model and made your dependincy container control under there.
Related
I'm building an API in .NET Core 3.1. I try to decouple this project in the typical 3 layers. Instead of having an UI layer, I have the API project with the controllers. I also have a class library project for the logic, and another class library project as the data access layer.
I'm trying to use dependency injection over all projects. My problem is, that I have, until now, registered my interfaces and classes as services in the ConfigureServices method in startup.cs, in my API project.
But that would mean, that the logic, and the data access layer would reference the API project. To solve this, I thought, it would be the best, if I move the DI container into his own "mapping" class library project and reference this in all other projects. Would that be a good practice?
If yes, how could such a project look like, how to setup the container and how will it be instantiated in the API's project ConfigureServices method in startup.cs?
But that would mean, that the logic, and the data access layer would
reference the API project
I don't think it should, just opposite, API project will be solution entry point, sole project which "knows" about all other dependencies and glue them together.
Other projects need to reference IServiceCollection Interface, which can be done by installing Microsoft.Extensions.DependencyInjection NuGet package.
Every project can introduce own "registration" method, which can be called by entry point.
// In Logic project
public IServiceCollection AddLogic()
{
services.AddSingleton<MyLogic>();
// Add other logic types
return services;
}
// In Data project
public IServiceCollection AddDataAccess(string connectionString)
{
services.AddTransient<IRepository, SqlRepository>();
services.AddDbContext<MyDbContext>(o => o.UseSqlServer(connectionString));
return services
}
// Startup
var connectionString = Configuration.GetConnectionString("MyDatabase");
services.AddLogic();
services.AddDataAccess(connectionString);
Only way where other projects need to reference API project is when you are using some types from API project. If this the case, then move them to the project where they are going to be used or introduce another project which both API and other project can reference.
I have a visual studio solution with a couple of C# projects. One of them contains my domain classes and has no infrastructure dependencies and another contains classes that depend on various 3rd party libraries, it's what you'd call an infrastructure project.
For each class in my domain project I have to write a corresponding class in my infrastructure project which contains just some boilerplate code required for using a feature of one of the 3rd party dependencies so I'd like to generate that automatically whenever my domain class is changed.
I was able to generate the classes containing this boilerplate code by creating a source generator with a ISyntaxReceiver that adds the abstract syntax tree of my domain classes for which I need to generate the boilerplate code to a list which is then used by my source generator to create the required classes. I then added this source generator as a project reference to my domain project but I have a problem: the infrastructure classes I need to generate inherit from a class of a 3rd party dependency so I have to add that 3rd party dependency to my domain project.
What I tried to do was to add my source generator as a project reference to my infrastructure project (which already references the 3rd party dependency, and also my domain project) but the source generator does not run because the ISyntaxReceiver's OnVisitSyntaxNode method does not get called for any of the classes in the referenced domain project.
Does anyone know if it's possible to create a source generator that generates code based on classes in projects referenced by the project that references that source generator?
I am aware of the AnalyzerAdditionalFiles, but seems like that should be used for making generation decisions based on more than just C# code
I was wondering if its possible to have multiple Entity Framework Code First Projects migrating onto a single Database? I've tried looking and found this link but I think the instructions were kind of vague, so I made a list:
Done (created a new class library)
Does the new class library have to reference my project? Isn't it the other way around?
What are model snapshot files? Do I move my models also?
Where is this located? Is it in the class library?
What is the startup assembly? Is it my initial project that was referenced by the class library?
Add-Migration NewMigration -Project MyApp.Migrations (What is MyApp.Migrations)
I have this solution in VS 2017 which has multiple projects:
Example.DomainModels
Example.DataAccess
Example.Infrastructure
Example.Web
So well, my Web project references Infrastructure and the Infrastructure project references DataAccess as well as DomainModels projects. The solution is working fine.
However, if inside my Web project, if I try to access any of the entities from the DomainModels, I can easily access that without any errors, even though Web project doesn't have any reference to the DomainModels.
Can you please help me understand how this referencing of the project works? Is it because the web project has indirect reference to the DomainModels (Web -> Infrastructure -> DomainModels)?
Thanks.
Indeed , as per your comments web will have reference to all other projects
When you compile , The Infrastructure will be having references dataaccess and domain model namespaces attached to it hence you are able to access the types or namespaces present in dataaccess and domain models from web since you are refering Infrastructure from web .
Please investigate the Onion architecture: https://social.technet.microsoft.com/wiki/contents/articles/36655.onion-architecture-in-asp-net-core-mvc.aspx
The Domain Model should not reference anything. In order to achieve this; you should investigate dependancy inversion. I asked a question recently about dependancy inversion here: Execute code in a class library when you do not have a reference to that class library
If you want to divorce the domain layer from the web then you could introduce a service layer.
I always see that there are app.config's in dlls and then website has web.config.
At the run time mostly web.config passes data to all the portable libraries.
These configuration are passed as properties of portable library class. ConfigurationManager is used to get the values from config file.
Now the problem, In my current project they have configsectionhandler in webapp project/folder.
and my project folder structure is like
Main
WebApp
BusinessObject
ThirdPartyWebserviceCall
and as usual webapp project has reference to BusinessObject and BusinessObject has reference to ThirdPartyWebserviceCall.
Now if I want to use configsectionhandler in ThirdPartyWebserviceCall I will have add a circular reference to
webapp.
Does this design seem ok? It looks realy flawed to me.
Is there other standard pattern to access configuration values in the libraries.