I have an application (NET Core) with many assemblies:
WebAPI (contain view models and consume DTO)
Services (contain DTO and consume Domain entities)
On WebAPI assembly I registered automapper profiles automatically with this line:
services.AddAutoMapper();
With this line I can convert view models to DTO (and backwards)
But I need register profiles located on Services layer to convert DTO to Domain entities (and backwards)
Evidently, Automapper not found this profiles.
What's the best way to register profiles from different assemblies?
I use services.AddAutoMapper(params Assembly[] assemblies).
for example:
services.AddAutoMapper(
typeof(Startup).GetTypeInfo().Assembly,
typeof(Class_In_Other_Assembly).GetTypeInfo().Assembly
);
Related
In the asp.net core projects:
What is the best way to share a controller with MVC Views to another project?
Is it any way to build a controller with Views as a component in the assembly and share it to the different projects.
In other words how to not just simply copy code and how to reuse it to another project.
Yes its a new feature in ASP Core called Application Parts.
It allows you to store your ASP Core Controllers/Views etc in a separate assembly and then you can include/share it as Application Parts/Dlls which is new in ASP Core, the sample code from MSDN is linked above for ASP Core.
In the ConfigureServices method of your Startup class just add this:
// set this up
services.AddMvc().AddApplicationPart(assembly).AddControllersAsServices();
Where assembly is the name of your instance Assembly with your controllers & Services, then you can load it either getting it from any included type or like this:
var assembly = Assembly.Load("YourApp.NameSace.AssemblyName");
Another nice ref implementation and explanation
I am using the ASP.Net BoilerPlate, a starting point for new modern web applications using best practices and popular tools. I am making an MVC, Web API, single page web application.
But I have noticed that based on the documentation that the Nlayer is based like bellow: where you can see it better on the link (https://aspnetboilerplate.com/Pages/Documents/NLayer-Architecture)
What is strange for me is that the management of DTOs and DTO mappings are made on the Application layer, I tough it would be made on the Web Layer on the ASP.Net MVC Controller or on the Web API Controllers, that would call the Application Layer and from the Controller it would make the mapping of DTOs.
But it seems that the MVC Controllers are not even used according to it's example linked on the documentation (https://www.codeproject.com/Articles/1043326/A-Multi-Tenant-SaaS-Application-With-ASP-NET-MVC-A).
If I make the DTO mapping in the Controller and make the controller Application layer responsable only to call the Service and retrieve Entities is not a better practice ?
I use ASP.NET Identity 2.0 in an ASP.NET MVC5 project that is composed of three layers; Web application (presentation layer), Unit Test (test project) and Class library (data layer). Normally IdentityConfig.cs is located in the App_Start folder of Web application but as I implement a Group-Based Permissions Management as indicated on this page I want to keep all the domain models and IdentityConfig.cs file to the Identity folder in data layer project instead of the web project (presentation layer). Because IdentityConfig.cs needs to access DbContext class that is placed in my data layer project. Is there any problem doing this? On the other hand, could you please explain a little bit what is the App_Start folder?
Here is the ASP.NET Identity folder structure in my project below:
DataLayer (class library)
Concrete EFDbContext
Entities (my entity classes except from ASP.NET Identity entities)
Identity
ApplicationGroupManager
ApplicationGroupStore
GroupStoreBase
IdentityConfig
IdentityModels
PresentationLayer (Web app)
App_Start
Controllers
AccountController
GroupsAdminController
ManageController
RolesAdminController
UsersAdminController
As long as you have asp.net identity, you will have to add reference to it in the presentation layer (web project) and the configuration will be kicked off from there.
If you moved it to the data access layer, then you put a security concern in the data access which is not right.
Normally, I just leave it in the web project and create my own user class and link it to the ApplicationUser class through its Id, but if you must seprate it, then you can put the IdentityConfig in a separate library that handles the cross cutting concerns like security, logging and exception handling as this layer will be working across all layers.
In the data access, you can have a custom user and role stores and put the configuration in the cross cutting library and link all of that in the presentation layer as this is the kickoff point for your web app.
The App_Start is justa normal folder that has the code that will be executed when the application starts, and you can put this code any where else, it is all called by the Global.asax file
I'm facing this problem with EntityFramework 5 (VS 2012). I have the following projects in my solution:
I'm using database first and the designer
Data. Where my entities model and entities are.
Security. Where the business logic for security is.
Web. The web UI
Security has a reference to Data so it can use the model and entities to retrieve data from the database. In Security I have a method the returns a list of MenuOptions (this is an entity in the project Data) to the UI (Web project). In the Web project I then want to iterate the list of MenuOptions to build a menu. The problem is that I don't want to add a reference to Data in my Web project just to be able to have access to the entities. Then, how can I make the entities in Data visible to Web without adding a reference to the full project? (I only want the entities to be accessible to the UI).
Separate the entities in a dll (or project) put your DbContext inherited class and entities mapping configuration in another.
This way you can distribute your entities dll in different projects without sharing DB access items.
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
How we do MVC – View models
ASP.NET MVC View Model Patterns
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.