I have a question regarding the Nop.Core, Nop.Services and Nop.Data libraries used in Nopcommerce.
My understanding is that these libraries are software layers that sit beneath the presentation layer (since they are not in the presentation solution folder) and therefore should have no concern with presentation logic. Is my understanding correct?
I have been trying to create a console application (using the dependency injection setup from Nop.Web) and am running into the following dependency injection issues where the Nop libraries require knowledge of the web presentation layer:
1. An instance of IHostingEnvironment is required in Nop.Core/Infrastructure/NopFileProvider.cs and Nop.Services/Media/BaseRoxyFileman/BaseRoxyFilemanService.cs, DatabaseRoxyFilemanService.cs and FileRoxyFilemanService.cs.
IHostingEnvironment provides web hosting information such EnvironmentName, ApplicationName, WebRootPath, WebRootFileProvider, ContentRootPath and ContentRootFileProvider. The instance of IHostingEnviroment that Nop.Web uses is provided by the WebHost when Nop.Web/Program.Main() is called to start the application.
The NopFileProvider uses the IHostingEnvironment so that calls to MapPath(string path) can join the ContentRootPath to the path parameter.
Should the Nop.Core and Nop.Services have knowledge of the web server path?
2. An instance of IApplicationLifetime is required in Nop.Core/WebHelper.cs.
Microsoft.Extensions.Hosting.IApplicationLifetime is used in this class to stop the application in the RestartAppDomain() method.
Note: As a side note, this API is also now marked as obsolete.
Should the Nop.Core have knowledge of how to stop the web server?
So I am a little confused as to the responsibilities of these layers in this solution. I was hoping that I could just add the Nop.Core, Nop.Services and Nop.Data libraries to my console application but as these layers require knowledge of the web environment it is not as straightforward.
I can work around this in my console application, but my main concern is that if responsibilities are being ignored, that the architecture of NopCommerce does not go off track.
Does someone know if this is the case or is my understanding of the layer responsibilities incorrect.
Thanks
Should Nop.Core and Nop.Services have knowledge of the presentation layer?
- 96
- 1282
- 9/5/2013
- New Zealand
Starting with NopCommerce 4.0, when Nop moved to ASP.NET core, it seems like the Nop team gave up completely on keeping concerns separated. Web stuff is now baked into the core libraries. A big shame if you ask me.
Good luck writing a console app. I tried and gave up.
Instead what I did was stripped down the Nop.Web project to the absolute bare minimum and create my own controllers for basic tasks. This gives me the ability to programmatically add products, attributes, and things like that, which saves me quite a bit of time. But it's a dirty hack, and not something I'd put into production.
Also worth mentioning that, even if you were able to get the nob libraries working in a console app, certain things will never work since they rely on the filesystem (for example, product images).
The better way to do this would be to write a plugin to provide API endpoints, and then call those endpoints from your console app.
Good luck writing a console app. I tried and gave up.
Instead what I did was stripped down the Nop.Web project to the absolute bare minimum and create my own controllers for basic tasks. This gives me the ability to programmatically add products, attributes, and things like that, which saves me quite a bit of time. But it's a dirty hack, and not something I'd put into production.
Also worth mentioning that, even if you were able to get the nob libraries working in a console app, certain things will never work since they rely on the filesystem (for example, product images).
The better way to do this would be to write a plugin to provide API endpoints, and then call those endpoints from your console app.
- 210
- 1678
- 2/9/2018
- United Kingdom
I'd like to see on the roadmap an official 'baked in' api covering most/all core functions, and some client wrapper classes to facilitate stuff like batch product creation/updates. I appreciate there are 3rd party api add-ons, for which I am grateful. But for me this should now be at the core of the platform and ready to roll on each new release
- 105
- 1036
- 5/25/2013
- United Kingdom
timmit wrote:
Sorry it's taken so long to reply to your message. Not had the chance to respond until now.
I agree though. It is a shame that some of the web functionality is becoming integrated into the service layer rather than being kept separate.
I did manage to get the console application working. You are right though about certain services requiring knowledge of the web file system. And it is these services that make it harder to setup the console application.
In a nutshell, to set up the console application to use the services and repositories I had to:
1. Create /appsettings.json and /App_Data/dataSettings.json files in the console application.
2. Create an instance of IConfigurationRoot.
3. Register my own instance of IHostingEnvironment setting the ContentRootPath to the current directory and the WebRootPath to a dummy /wwwroot directory in my console application. The dummy /wwwroot path also had to have a placeholder.txt file so that it would be copied to the output directory as the service checks for the presence of this file. Nice!
4. Register a blank instance of IApplicationLifetime which is now required in the core WebHelper service since the release of version 4.20.
5. Call nopcommerce ServiceClassExtensions.ConfigureApplicationServices(IConfiguration, IHostingEnvironment) to register the application services.
At this point the application is set up (at least for my usage).
6. Resolve an instance of the service you require in nopcommerce using:
If anyone is interested in the actual details of the code and structure of this console application then please let me know and I can create a post describing how I set it up. But as 'timmit' has already mentioned, certain things may not work (such as the file system).
Starting with NopCommerce 4.0, when Nop moved to ASP.NET core, it seems like the Nop team gave up completely on keeping concerns separated. Web stuff is now baked into the core libraries. A big shame if you ask me.
Good luck writing a console app. I tried and gave up.
Instead what I did was stripped down the Nop.Web project to the absolute bare minimum and create my own controllers for basic tasks. This gives me the ability to programmatically add products, attributes, and things like that, which saves me quite a bit of time. But it's a dirty hack, and not something I'd put into production.
Also worth mentioning that, even if you were able to get the nob libraries working in a console app, certain things will never work since they rely on the filesystem (for example, product images).
The better way to do this would be to write a plugin to provide API endpoints, and then call those endpoints from your console app.
Good luck writing a console app. I tried and gave up.
Instead what I did was stripped down the Nop.Web project to the absolute bare minimum and create my own controllers for basic tasks. This gives me the ability to programmatically add products, attributes, and things like that, which saves me quite a bit of time. But it's a dirty hack, and not something I'd put into production.
Also worth mentioning that, even if you were able to get the nob libraries working in a console app, certain things will never work since they rely on the filesystem (for example, product images).
The better way to do this would be to write a plugin to provide API endpoints, and then call those endpoints from your console app.
Sorry it's taken so long to reply to your message. Not had the chance to respond until now.
I agree though. It is a shame that some of the web functionality is becoming integrated into the service layer rather than being kept separate.
I did manage to get the console application working. You are right though about certain services requiring knowledge of the web file system. And it is these services that make it harder to setup the console application.
In a nutshell, to set up the console application to use the services and repositories I had to:
1. Create /appsettings.json and /App_Data/dataSettings.json files in the console application.
2. Create an instance of IConfigurationRoot.
3. Register my own instance of IHostingEnvironment setting the ContentRootPath to the current directory and the WebRootPath to a dummy /wwwroot directory in my console application. The dummy /wwwroot path also had to have a placeholder.txt file so that it would be copied to the output directory as the service checks for the presence of this file. Nice!
4. Register a blank instance of IApplicationLifetime which is now required in the core WebHelper service since the release of version 4.20.
5. Call nopcommerce ServiceClassExtensions.ConfigureApplicationServices(IConfiguration, IHostingEnvironment) to register the application services.
At this point the application is set up (at least for my usage).
6. Resolve an instance of the service you require in nopcommerce using:
var service = EngineContext.Current.Resolve<INOPCOMMERCESERVICE>();
If anyone is interested in the actual details of the code and structure of this console application then please let me know and I can create a post describing how I set it up. But as 'timmit' has already mentioned, certain things may not work (such as the file system).
