I have one project with multiple libraries. The problem I have is that I can’t access some libraries from others, as when I add a reference I get an error about circular dependencies. I assume I need to create an interface but I am not really sure how to structure it. Here is an example of what I have:
My references are setup like this:
WebApp (This is an ASP.Net web site) - Has Reference to BusinessLayer Class Library and Utilities Class Library
Data Class Library (This library provides abstract database functionality) - has no references
BusinessLayer Class Library (provides a business logic layer) - has references to Data Class Library, DataLayer Class Library, and Utilities Class Library
DataLayer Class Library (provides a layer that directly interfaces with the database i.e. CRUD commands) - has references Data Class Library and Utilities Class Library
Utilities Class Library (general library that are used across all layers) - has no references
For the most part this is fine. But, I have a class in the Utilities Class Library that needs to reference functions and properties in the WebApp and BusinessLayer Class Libraries. I cannot add a reference to these projects, as that would create a circular dependency. So, how would I go about setting up the Interface and the correct references?
The way you have designed your application is very similar to architecture pattern defined
here
As for your utility class, you can define an interface in BusinessLayer/domain layer and implement that interface in utility layer. Please note it should only return types defined in business layer/domain. This way you will get a nice separation of concerns. If let's say your web needs to consume this utility method, you can apply transformation to convert your domain type into web project specific type. This way you won't run into circular dependency.
I created a sample application based on these principles, you can refer to my github
project.
It sounds like you need to move those common functions out of webapp and into your utilities library. I don't think you should be referencing your web app from any of your other libraries.
Related
I am building asp.net core 2 modular application, I was having one module but now I am about to create another module and I get to the point that I need to develop a communication between the two modules, I need to use a model class from module A in module B, how can I achieve this without any dependencies between the modules
I do not want to put the model class in a shared project nor creating references between modules.
Modules should not depend on another module, it can depend only on contracts. Some example. You have module Awith intrerface IModuleAService and class that implements it, ModuleAService. Module B requires for his service ModuleBSerice implementation of IModuleAService. So create separate assemblies:
ModuleA.Abstractions: containts IModuleAService and other contracts
ModuleA: depends on ModuleA.Abstraction, contains class ModuleAService that implements IModuleAService
ModuleB: depends on ModuleA.Abstraction.
And at your startup class you need register all modules. IoC will make all workds for you. If later you would like to seperate app into two, it will be easy. Case your need to
implement proxy to access ModuleA.
i wanna know if it's possible to inject dependency for a class constructor as it is injected for controllers, i have the following cenario as an example:
An AccountController which depends on an AccountRepository like bellow:
public AccountController(IAccountRepository repository)
The dependency is injected perfectly using Unity DI, which have the following configuration:
container.RegisterType<IUserStore<ApplicationUser>, UserStore<ApplicationUser>>(new HierarchicalLifetimeManager(), accountInjectionConstructor);
container.RegisterType<UserManager<ApplicationUser>>(new HierarchicalLifetimeManager());
container.RegisterType<IdentityDbContext<ApplicationUser>, ApplicationDbContext>(new HierarchicalLifetimeManager());
The problem is that i have a class AuthorizationServiceProvider which also needs the AccountRepository... In this case, how would i instantiate or use this AuthorizationServiceProvider class without having to instantiate and provide it all the dependencies?
Provider = new SimpleAuthorizationServerProvider>(),
This provider is set inside the Startup class and called before the Unity DI config initializes...
Here the visual studio complains that there's no argument given that corresponds to the class constructor, but if i provide a new AccountRepository i'd have to provide all it's dependencies as well, (ApplicationDbContext context, UserManager userManager) which are already provided for the Unity DI when creating the controllers....
Could somebody help me please?
Thanks in advance...
how would i instantiate or use this AuthorizationServiceProvider class without having to instantiate and provide it all the dependencies?
You can't. This is actually the core of what we're trying to achieve with Dependency Injection. Your application code should let go of the control over its dependencies. This means that your application code should not create an AuthorizationServiceProvider. Rather, it should let a third-party provide this dependency. Typically, this means you require the dependency be supplied using Constructor Injection.
Letting application code create these dependencies itself causes problems, typically referred to as the Control Freak anti-pattern or Dependency Inversion Principle violation. It causes strong coupling, which can hinder maintainability.
When working with Dependency Injection, this third-party is called the Composition Root. The Composition Root is:
a (preferably) unique location in an application where modules are composed together.
With DI, only the Composition Root will create graphs of objects. You are using Unity, which is a DI Container. The DI Container acts as the Composer, which is part of your Composition Root.
Instead of using a DI Container, you can build the object graphs by hand, which means you will have to create a complete tree of dependencies at once. This practice is called Pure DI. Still, the Composition Root is the location where those object graphs are created; with or without a DI Container.
Your view of DI might be troubled by the use of the standard Identity template that Visual Studio provides. From a design and DI perspective, however, this template is horrifying.
Either way, all these stated concepts, patterns and anti-patterns are described quite thoroughly in the book Dependency Injection in .NET by Mark Seemann.
Hi i want to know what is meant by modules in a project??how they are classified and how many modules we can have in a project?can anyone explain with simple examples??What modules we can have in a typical online shopping website?
In .net context I believe one can draw 2 meanings not sure what specific you are looking for.
One is modular programming by following design principles like "Separation of concerns", "Single Responsibility", "loose coupling". This means divide you code into classes based on these principles and further group these classes again based on these principles into modules.
In ASP.NET or C# or in general we create class library projects and use them across the entire project. Like all the logging functionality is put in some classes and these classes are include in an class library project which can be called "Logging module". Whenever you need logging in any of the project you can include this module and use the functionality.
Some examples:
Web module for HTTP requests ( The WebApp)
Repository and Data access Layer modules. (DAL code)
Models module containing all the business entities.
WebService modules for integrating with other apps.
Logging for debugging and problem identification
Infrastructure/Utility modules for utility like functionalities and
application configuration.
Business logic modules.
Transaction gateway module.
Other way to define module in .net is they are PE files and I believe they have extension .netmodule which contain Metadata but they do not contain the assembly manifest. To use a module you have to create a PE file with the necessary assembly manifest.
Create a module:
csc /t:module ufo.cs
Create assembly using the module:
csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs
Above 2 commands are from this link
The module is an external code that you plugin on your site and runs in order to do some actions.
(source: codeguru.com)
We make and use modules to have the ability to share the actions of the module with others with out giving the source code, and vice versa, we use modules from other that we do not have access to the source code. Or we can simple use module for have the ability so simplify our code and remove it easy if we do not need it.
We can have as modules as we like, but each module place extra overhead on our code - after all is need to make more thinks there.
More about modules: http://www.codeguru.com/csharp/.net/net_asp/article.php/c19389/HTTP-Handlers-and-HTTP-Modules-in-ASPNET.htm
How to create module: http://support.microsoft.com/kb/307996
My ASP.NET application uses only 1 SQL Server 2000 database and no more than 50 tables in it. And I copied an instance of the database to run on my develop PC, so I need to switch the connections between dev and release.
The problem is, I had created multiple class libraries in my business layer, and each class library has a LINQ to SQL class. Now I find it difficult to make all of the DBML files in the different projects use the same connection string.
So is my design wrong? Should I only use 1 class library? If I continue to use multiple class libraries, how do I ensure the same connection string is used in all libraries in release mode?
Put your DBML in its own class library (assembly), and reference it in your other class libraries. That way, you can make your changes to the DBML in one place.
If you have partial classes that implement business logic, I would go ahead and put those in your other class libraries.
I am a total newbie on Prism. I have been getting to understand a lot from questions on SO and from various Blogs. I am using latest build – V2
I want some explanations on things that may be pretty easy things for you guys but it’s just not getting into my brains (small one for that).
Instead of doing it all right the first time , for which I have spent more than two weeks looking at various blogs, webcast …., I thought to start a project and learn. The amount of information on those hundreds of sites was overwhelming and difficult to digest.
Currently my project is setup like this
Shell -- Menu Module- ViewModel - - -> Menu Service -- -- > Menu Repository --- Data
All are in different assembly
MyShell --- MenuModule ---MyServices -- Myrepository
Shell is required to reference modules ( thought I am sure I can add it using string) later on .
ViewModel has a reference to View - Can live with it for now
View Model requires to use menu service and menu service uses repository
All are built with constructor injection. I have it working now by having module reference MyService and Myrepository projects and then registering types at module level.
But this does not feel good. I don’t want to hard reference any projects. If we are referencing projects why use IoC. In MenuModule.cs ( which is in the root of module) I can register views with unity container
I think I am getting a feel that the answer to this one may lie in the first question
Is Configuration file the answer/
Should I use configuration file for
true decoupling?
If (somehow) we can
register types from code, should we
register types at module level ( I
don’t want to have hard reference to projects)
I need to know the
Interfaces in advance so do you
recommend separate assembly for just
Interfaces?
Bear with me if the questions sound real stupid
You don't need a configuration file for true decoupling. All you need is to register your types in your shell's bootstrapper. I usually break up my projects and refs like this.
Contract Assembly
(Contains only a few simple types and interfaces)
Referenced by:
Shell
Modules
Shell
(Contains concrete implementations of interfaces defined in Contract assembly)
Referenced by:
No one
Modules
(Declares dependencies on interfaces defined in Contracts assembly, for instance IMenuRegistry)
Referenced by:
No one (I use a Directory Module to search for modules in a directory)
Here's a sample project I put together. In this sample I reference the module from the shell for simplicity's sake, but you can remove that reference and use a directory module catalog to load the compiled module at runtime:
http://dl.getdropbox.com/u/376992/CAGMenus.zip
Hope this helps,
Anderson
You're definitely on the right track. Use the configuration file to register your types, and put the interfaces in a separate assembly.