startup Blazor server side
I already tried to register classes in scoped but it doesn't work
class where I send data to another class following the mvvm architecture
I also use iprovider service but in the same way I can't make it work.
class container
class where I implement the IServiceProvider
Related
I'm new to .NET Core and Blazor, with mostly WebForms and MVC experience.
All the Blazor documentation and tutorials I've found use a separate API project and access data through HttpClient and Json serialization/deserialization. I see why this would be necessary for client-side Blazor using WebAssembly, but for Server-Side Blazor using SignalR what's the best way to access the database directly from the components' .razor files using an Entity Framework DbContext?
For example, in an MVC controller you can just do something like:
private ApplicationDbContext context = new ApplicationDbContext();
and then query the data by doing something like:
var things = context.Things.Where(t => t.ThingAttributes == something);
Is there an approach that is this clean and efficient when working with components in server-side Blazor?
Sorry for the broad nature of this question, feel free to point me to blogs, docs, or tutorials I should have already read. Thanks!
What you call a controller should be turned into a service class, that retrieves data from the database, and pass it to the calling methods. You should add this service to the DI container in the Startup class. To use this service in your components you should inject it like this:
#inject DataService myDataService
I think that the Blazor templates come with sample how to define such a service and use it in your components.
Here's a link to a sample by the Blazor team how to create a service and how to use it in your components. The service doesn't use Entity Framework, but this is something really minor I'm sure you'll cope with.
I have been working with for a while but somehow never thought about this. Every aem project that I have worked on, has one similarity in their code structure. There is an interface for every service written.
My question is why do we need a interface for every service?
Can #reference or #inject not use the services without an interface?
Using interfaces is a good practice to decouple the user of a service from the implementation. In many cases you even want to have an API bundle so the user of the service does not need a maven dependency to the implementing bundle.
On the other hand you are not required to use interfaces. Especially when I wire components inside a bundle interfaces are often an unnecessary layer. In this case simply export the service directly with the class.
See here for an example:
#Component(service = DistributionMetricsService.class)
public class DistributionMetricsService {
...
}
and here for the client code:
#Reference
private DistributionMetricsService distributionMetricsService;
So the main difference is that you have to specify the service property if you want to export a component with its implementation class.
Ok, I am uisng GWTP, it got Client, Server & Shared package.
I have a Util class in client.
my.client.Util.java{
public static String method1();
//more methods here
}
In server i have
my.server.GetDataActionHandler{
///Should I do like this
String s=my.client.Util.method1();
}
Is it safe to do that or I should put Util into shared package, like this
my.shared.Util.java{
public static String method1();
//more methods here
}
What is the different if we put a Util in shared package? is it safer or any other good reasons?
client is as safe as shared, these are just names and conventions.
By placing your class in client though, you lose the indication that you're using it also on the server side, where client-specific code won't run.
By placing it in shared, you're signaling to yourself that you should make sure the code your put in the class can effectively be used in both the client and the server.
Read here about GWT MVP atchitecture
Read more here about GWT Architectural Perspectives
Accessing client side code from server side will become your code tightly coupled. Shared package is used for this purpose but still its not for any UI specific code. Shared packages is used to define some DTO (Data Transfer Object) and Utility classes.
There is no meaning of accessing any GWT UI specific utility classes at server side.
Try to decouple your code in such way if in future you want to use your server side classes for Swing application or any other web application other than GWT then you can easily incorporate it. Think about it.
I’m using GWT 2.5, and RPC to exchange information between client and server.
I’m trying to define the interface that extends RemoteService and another one CRUDService<T> that has among others (CRUD methods) the following method:
public Class<T> getDtoType();
But this method is only intended to be user by the implementation, on the server side.
Is there a way not to expose this method to client side (transient method)?
Otherwise I’m getting an error, when I compile the project, saying Class<T> does not implements Serializable nor IsSerializable.
Could anyone help me?
Not possible. Atleast not without hacking gwt-dev and rpc related code for service proxy generation.
1) SampleService extends RemoteService, CrudService<String>
2) SampleService extends CrudService<String> ( where CrudService extends RemoteService )
In both above scenarios Async Interface cribs first. If you fix it then GWT proxy generators crib about Serialization interface.
Can anyone please explain how I can avoid using an aync class when using dto to serialize an object in a service?
If I understand your question, DTOs are only for passing data to the client side in a GWT application, when you can't pass the server side object directly. DTOs have nothing to do with the async classes, which the GWT compiler needs for RPC service calls.