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.
Related
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.
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.
I have WCF service responsible for exposing services and connecting with local database MSSQL.
I generate client of this service in a few projects, e.g. Proj1 and Proj2. In Proj3 I have references to Proj1 and Proj2. I want to use types from database, but they are in different namespaces (Proj1.ServiceReference.TablePerson, Proj2.ServiceReference.TablePerson).
How can I resolve this problem? I suppose using sth like converted/adapter for each type (table) is not the best solution.
Have a shared dll with your classes and reference it form the server and from the client.
When you create a wcf reference, make sure that "reuse types from existing assemblies" is set. This will make generated proxies rely on the shared dll code and WILL NOT create new proxy types each time you create a web reference.
What you should do is create a separate project to create your service references in, and then have Proj1 Proj2 and Proj3 all reference that project. That way you will only have to generate one set of classes for your service reference.
I've searched for an answer on google using:
"The type 'Microsoft.SqlServer.Management.Smo.Server' is defined in an assembly that is not referenced."
Why does using Microsoft Sql Server Management Objects (SMO) in the DAL require references to SMO dlls in a referenced project?
using sql smo in referenced projects
sql smo in layered solutions
sql smo reference requirements
and probably a few others and have not found a solution or explanation to this issue.
Admittedly, I'm only a journeyman googler, so if someone wishes to power level me and point the way to an existing resource, I'll gladly go spelunking from there.
Here's my set up:
I've got a layered solution: DAL, Business Logic, Services, UI. There's a hosts project that hosts the services. I'm actually using the VS2010 extension layerguidance.codeplex.com, which is quite nice, to set up all these projects. I'm using SQL Server 2008 Express and SMO v 10. All solution projects are referenced using Project References. All projects compile to a common top level Bin folder.
Now the problem:
Among the classes in the DAL I have an SmoTasks class which handles interfacing with SMO objects and a Utilities class which abstracts from SmoTasks and provides acces to its functions without requiring any SMO objects for parameters, so that referencing projects (read: Business Logic Layer) can interface using non-SMO types. All is well in the DAL, it compiles fine, the methods pass their tests - it feels good about its place in my world. Then in the BLL I have a component which handles using the Utilities class to perform database configuration for the application which will be exposed via the services. The BLL uses a project reference to the DAL and sees the DAL classes (a la intellisense) as expected. When I compile though, I get:
The type 'Microsoft.SqlServer.Management.Smo.Server' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'.
The code in BLL looks like this:
public bool CreateTables(string connectionString)
{
bool result = default(bool);
// Data access component declarations.
Utilities utilities = new Utilities();
// Step 1 - Calling CreateTables on Utilities.
result = utilities.CreateTables(connectionString);
return result;
}
The line the error points to is:
result = utilities.CreateTables(connectionString);
I could, obviously, add the SMO references to the BLL and then the BLL would be happy, but that violates my design goal of loosely coupled projects. If I add the SMO assemblies to the BLL, it compiles and then referencing BLL objects in the services layer doesn't cause a complaint. My question is, why? More specifically: Why does the BLL need references to SMO when the Utilities class in the DAL already abstracts away the SMO types?
What I want is everything database related to live in the DAL (duh) and only business logic in the BLL (double duh). Is there another way to achieve this using SMO that I have overlooked?
Thank you for your valuable time and answers, I humbly await your responses
Edit:
I've adjusted my solution based on suggestions by Chris, verified that I'm using project refs (I am), readded the references to SMO in the DAL using Muse.VSExtensions to add GAC reference, before I had been browsing and adding manually, then I went ahead and set Copy Local = True for those assemblies just to be doubly sure they're around... but I'm still stuck with this annoying compile error.
I think this boils down to how things are referenced in your solution. So I'm going to take a couple guesses.
It sounds like your DLL references the DAL as an assembly instead of as a project reference.
During compile time Visual Studio copies everything it thinks is necessary to the projects BIN directory. If you reference an external DLL (DAL) then it will copy that DLL only to your BLL's BIN directory.
What you need to do is get it to copy the SMO assemblies as well OR have those SMO assemblies available through the GAC. Personally, I don't like GAC'ing things, so I'll ignore that.
There are three ways of doing this. The easiest is to simply add a reference to those other assemblies to your BLL. Obviously that's not what you want.
The second way is to reference the DAL project as a project reference. This will allow Visual Studio to detect the extra dependencies and copy them accordingly. This is also not exactly what you want as well.
The third way is to copy them as part of a build step. Right click on your BLL project and go to Build Events. In the Pre-build event command line put in the commands to copy the necessary SMO files to your BLL projects BIN directory.
You'll have to do this again for the main service project as well.
It's depressing to answer your own question with a mea culpa, "I'm an idiot"... but, well, I'm an idiot:
In Utilities there was an overload for the offending method which did contain an Smo.Server parameter. I removed that overload (an artifact from testing before refactoring) and voila, problem solved/idiocy confirmed! The interesting thing I learned here is that using the other methods of the Utilities class, which did not have overloads containing Smo objects, was absolutely fine, meaning even with a function in the Utilities class which required an Smo object for a parameter, as long as I didn't call that method or one of its overloads, the references resolved perfectly without a hitch. The new question I have, is why? Why does that overload's existence matter for reference resolution if I call another version of that function from a project higher in the dependency chain? Is there some internal loop where it goes over all versions of a function checking references if any version has been called...
I'm working on an MVC 3 project. I was told to get all the models and viewmodels out of the projects and put them in a class library so that they can be referenced from different types of projects. However, now that I've transferred all the viewmodels and models from the web project to a class library, and removed all the references to the web project, I cannot set reference to the class library from my web project with the reason stated in the question title. WHy is this happening? In my class library I'm not referencing the main project anywhere!!! Any suggestions? Thanks a lot!!
Experienced this earlier. Check the project that you are going to add if it has the reference to the project you are adding in it.
Example: Project A with reference to Project B. Then in Project B, you're adding Project A as reference.
well this usually happens for a reason, and this is that there is a cirrular reference,maybe not a direct one but an indirect one (through third project, how many projects do you have in your solution?).
In your library project remove all other projects references from solution, and try it again.
good luck
almir