I have a .Net core MVC application and a class library names UIServiceLayer. UIServicelayer has following classes:
public class Page.
internal class Widget.
internal class WidgetType.
--- some more internal classes related to UI objects.
internal class Data.
In UIServicelayer, only the Page class is public, and it is the sole interaction point with the UIServicelayer.
I have connection string stored in my .Net Core MVC application's appsettings.json file, which I need to pass to Data.cs class, so that it can establish connection with DB.
The problem is that I do not want to pass connection string through the Page.cs class, because Page class should not be concerned with anything other than UI page and widgets and stuff, and I also don't want to mark Data class as public, because I don't want my .Net Core app to interact with Data class directly.
Can anyone suggest me how to pass connection string to Data class from my .Net Core app?
Related
Good day all.
I have an asp.net core solution (NopCommerce 4.4) where I'm registering multiple classes that inherit from Microsoft.Extensions.Hosting.BackgroundService. These are using Dependency Injection to get access to several other classes at runtime.
Some of these DI classes need to know which specific class (derived from BackgroundService) they were instantiated in so they can return data specific to the background service that's "hosting" them. For example, each Background Service has it's own ECommerce Store it's responsible for processing data in.
How can I determine what Hosted Service is the "context" for the DI classes that it is requiring?
I am creating an ASP Core MVC application. Within my solution I have Web project (MVC) and a Core project (BLL/DAL).
I thought it would be a good idea to keep my persistence models and DbContext inside Core project as internal, since Web project should never need the persistence models or need to access context directly, it will get all it needs from services.
Core project has an IServiceCollection extension method which allows me to add the DbContext from service layer to the service container in MVC project without MVC needing direct access to it.
The issue comes when I need to use the DbContext inside my service classes in Core project. The service classes must be public for the view layer to access them, but I cannot inject DbContext into them via the constructor because it is internal.
If I want to make the DbContext public so it can be injected, I must also make all of my persistence models public since they are declared with DbSets in the context.
Do I really need to make all of my persistence models public or is there a way to resolve this?
First of all, you need to make Entity public, otherwise, you will not be able to access them in Service Layer. We should reference Entity from Data Access Layer instead of accessing ViewModel from Service Layer in Data Access Layer. And then, you could make DbContext public to be able accessed from Service Layer.
If you want to avoid accessing DbContext directly from Service Layer, you could consider implementing public Repository which will inject DbContext to handle CURD operations.
I've looked around - can't find the answer to this, even in lots of sample code.
I'm trying to compile a WCF Service Application that uses [datacontract] classes as parameters on the interface members, which are from a global C# class library... This is on the server side. When I import the service reference into the client, it's re-namespace-based the global class library classes, and generated a bunch of serialization code!
I cannot add a reference to the global class library in the client project and use the classes freely. this seems clunky. I've checked the button when importing the service reference "reuse types", but I don't know what that does, but it's not the right thing.
During the import of the service library, it allows me to specify the namespace for the about-to-be-generated proxy classes. I'm pretty sure this isn't supposed to be the same namespace as the classes used on the server side!
example:
GLOBAL CLASS LIBRARY
namespace SquallGlobal
[datacontract] class ProcessStartInfo{ }
WCF SERVICE
namespace Squall
[servicecontract] interface IJob{
[OperationContract] StartJob( SquallGlobal.ProcessStartInfo psi );
}
END USER PROJECT
WCF Service imported under namespace 'Squall_Imported'
using SquallGlobal;
if I want to call proxy.StartJob( ), I need to pass in a Squall_Imported.ProcessStartInfo, not SquallGlobal.ProcessStartInfo!
Thus, the final question: How do I keep the proxy-generation code from re-basing the namespace on global classes used in interface methods?
I'm building a Web API application using OWIN and hosting in IIS. I now want to preload some data from a database which can be used in the controller methods without loading the data from the database for each request. I have also followed this guide to setup Windsor as IoC container. Does anyone know how to properly set this up?
It's easy to do. In the Startup class, populate one or more classes with the database data. Do this as you would normally load data into a data store.
Register each of these classes with your IoC from the Startup class. It is best to separate the controller from data layer, so create a business logic layer or a repository layer that takes your data store class in the constructor like this:
public class Service
{
private readonly IDataStore _dataStore;
public Service(IDataStore dataStore)
{
_dataStore = dataStore;
}
}
Register the service with your IoC and you should be good to go.
Hope that helps.
We have an n-tiers architecture :
-a WCF Service that communicates with the database and handles all the business logic.
-an ASP.NET MVC website that communicates with the WCF service.
Here is a scenario of data serialization-deserialization from the database to the html view of a 'guitar':
-Guitar_1 a class generated by linq,
-Guitar_2 the DataContract exposed by the WCF service, and consumed by the ASP.NET MVC website.
-Guitar_3 the model passed to the View
When an end user wants to retrieve a guitar, Guitar_1 is transformered into Guitar_2 and then into Guitar_3. That's really not a problem but if the end user requests a list of guitars then all this process is repeated for each guitar (a loop).
If i had to programmatically handle all the serialization-deserialization stuff, i'd had only one class per layer. It could still be done for example on the wcf project by annoting 'DataContract'/'DataMember' on the Linq class, but if I refresh my database model all my annotations disappear (Same case ont the ASP.NET MVC project, refreshing the service reference deletes all the added code).
Also, Is it really more productive to use these automatic serializers? the time taken to write a serializer-deserializer takes as much time as annoting classes (DataContract/DataMember) and handling the conversion of class Guitar_1 to Guitar_2... Add to that the loss of perofrmance (Loop and conversion)...
What do you guys think? Do some of you code as in the old days because of this?
UPDATE: As suggested by 'Abhijit Kadam', I used partial classes when consuming a webservice, however, I found a better solution when using Linq2SQL : POCO classes.
If the main concern is that the model classes created by framework are automatically regenerated and you changes like annotations on such classes are wiped out THEN in this case you can use partial classes, info here. If the auto generated class is Employee. Then in separate file create a partial class Employee and include the fields in this partial defination that you want to annotate. This class will not be wiped out and regenarated. However when you compile the code the resultant Employee class will be combination of the Original Employee class + the partially defined Employee class.
Also converting from class Guitar_1 to Guitar_2 is OK and at times we have to do such things to meet specific requirements. I prefer JSON data to be transferred across the network wire like from WCF to MVC Web and then browser will fetch the json data from the MVC APP. Then I use frameworks like jsrender or knockout to render the data as HTML on the client side(browser). JSON is readable, compact and javascript and javascript libraries love json.