I love the Serenity MVC framework and would like to use it as much as possible. I am returning data from a web service and would like to implement the framework using the return List<>. I know it is built on the Entity Frame work, but is it possible to have an override where we can get the data from a web service rather than a database?
You should derive your request and response classes from ServiceRequest and ServiceResponse then you can accept any parameter type inside it, e.g:
MyResponse : ServiceResponse
{
Result: List< Something >
}
Related
I am converting code that was written in ASP.NET MVC to ASP.NET Core MVC. While I was converting the code, I encountered a problem. We used a method that has multiple parameters like this:
[HttpPost]
public class Search(List<int> ids, SearchEntity searchEntity)
{
//ASP.NET MVC
}
But when coding this in .NET Core, the ids parameter is null.
[HttpPost]
public class Search([FromBody]List<int> ids,[FromBody]SearchEntity searchEntity)
{
//ASP.NET Core MVC
}
When I place the ids parameter in the SearchEntity class, there is no problem. But I have lots of methods that are written like this. What can I do about this problem?
Can only have one FromBody as the body can only be read once
Reference Model Binding in ASP.NET Core
There can be at most one parameter per action decorated with [FromBody]. The ASP.NET Core MVC run-time delegates the responsibility of reading the request stream to the formatter. Once the request stream is read for a parameter, it's generally not possible to read the request stream again for binding other [FromBody] parameters.
MVC Core is stricter on how to bind model to actions. You also have to explicitly indicate where you want to bind the data from when you want to customize binding behavior.
I have used a solution where multiple parameters are sent as [FromBody] using a tuple:
[HttpPost]
public class Search([FromBody](List<int> ids, SearchEntity searchEntity) parameters)
{
//ASP.NET Core MVC
}
Currently I Have configured Identityserver4 as separated project + My WebAPI and store in DB Credentials in IdentityServer.
Now i have problem how to make CRUD(In my frontend API) to IdentityServer(I want from my API add Clients to IdentityServer)
How to make property?
From IdentityServer4.EntityFramework and IdentityServer4.EntityFramework.Storage, you have access to IConfigurationDbContext (once you've added the required services in ConfigureServices using e.g. AddConfigurationStore). Because this is registered as part of the Dependency Injection system, you can take a dependency on it in one of your controllers. e.g.:
public class ClientsController : ControllerBase
{
private readonly IConfigurationDbContext _configurationDbContext;
public ClientsController(IConfigurationDbContext configurationDbContext)
{
_configurationDbContext = configurationDbContext;
}
// ...
}
IConfigurationDbContext is an abstraction of a standard DbContext, with the following DbSet<T> properties:
Clients
IdentityResources
ApiResources
It also includes both SaveChanges and SaveChangesAsync - Everything one might expect from a DbContext. Because of all of this, you can CRUD each of these entities just like any other Entity Framework Core driven database.
One final thing to note is that there are both Models (in IdentityServer4.Storage) and Entities (in IdentityServer4.EntityFramework.Storage). There are also a few extension methods for mapping between these (e.g. ClientMappers.ToEntity).
Given all of this, you can create a Model inside of your controller (or perhaps somewhere much better encapsulated than directly there). Here's a basic example for creating a new Client:
var clientModel = new Client
{
ClientId = "",
ClientName = "",
// ...
};
_configurationDbContext.Clients.Add(clientModel.ToEntity());
await _configurationDbContext.SaveChangesAsync();
The Client class here comes from IdentityServer4.Models and is then converted to an Entity using a ToEntity extension method I hinted at above. Working with a Model and converting to an Entity is simpler than trying to manipulate an Entity directly - If you're interested, you can see the mapping that takes place here.
This works in the same way for ApiResources, IdentityResources, etc. Use the source code links I've provided if you want to find out more about those specifically, but the information I've provided here should have you covered.
In order to use IdentityServer4 and IdentityServer4.EntityFramework in your API project, you can just add the two references to your API project. After that, you can configure the DI in the same way (using AddIdentityServer in ConfigureServices), but you don't need to add the middleware (using UseIdentityServer in Configure). You can even just use AddIdentityServer().AddConfigurationStore(...) to set up the relevant services, as you don't need a signing key, etc.
One way you can do this is by bootstrapping the ID4 Quickstart (tutorial located here):
http://docs.identityserver.io/en/release/quickstarts/3_interactive_login.html
Other option is to use their quickstart seeds located here to speed this up:
https://github.com/IdentityServer/IdentityServer4.Samples
Now if you want to implement restfull login there are constraints around it (i wanted to find out as well) check out this question:
IdentityServer 4 Restfull Login/Logout
I am try to integrate SagePayMvc.dll into a ASP.NET Web API project which requires ControllerContext.RequestContext to be passed in order to form the Notification Url.
Currently I am experiencing some difficulties in achieving this, I need to pass the ControllerContext.RequestContext from this web api controller:
public class PaymentStartController : ApiController
{
private PaymentRepository paymentRepository = new PaymentRepository();
private SagePayHelper sagePayHelper = new SagePayHelper();
public Order MakePaymentInitial(Payment payment)
{
Order order = new Order();
order = sagePayHelper.MakePayment(payment, context);
paymentRepository.InsertVendorTXCode(order.VendorTxCode);
paymentRepository.InsertInitialPaymentDetails(order, payment);
return order;
}
}
I have tried to add a public ControllerContext controllerContext = new ControllerContext() below the SagePayHelper instantiation and then subsequently added var context = controllerContext.RequestContext, the problem with this none of the methods inside RequestContext are instantiated either so when SagePayMvc arrives at the point of building the Notification Url which is done inside an IUrlResolver interface an error is thrown.
Is there a way of mocking up ControllerContext.RequestContext, I have previously used RhinoMocks or would it be more prudent to revert to the way I previously implemented SagePayMvc down in the forms project (the forms project is an MVC 4 application that serializes and sends the form data to the web api).
Any advise would be much appreciated.
ASP.NET Web API uses completely different runtime components from ASP.NET MVC for representing the context and request/response messages. It looks like the API you are using is heavily tied to ASP.NET MVC, which makes it really hard to reuse in ASP.NET Web API unless you initialize the ASP.NET MVC content doing manual mappings. I think it would be easier for you to just use ASP.NET MVC for invoking that method expecting the MVC context.
I am looking at the new api that came out 2 weeks ago. It seems like
ReqDTO : IReturn<List<ResDTO>> { //... }
The "IReturn" bit seems to be optional? The DTOs in RazorRockstars demo project works without it.
This is a new addition in ServiceStack's New API which allows you to document the expected Response Type that the Request DTO will return, e.g. with
ReqDTO : IReturn<List<ResDTO>> { ... }
Which lets you call using any of the C# Service Clients with:
List<ResDTO> response = client.Get(new ReqDto());
If you didn't have the IReturn marker your client call would have to look like:
List<ResDTO> response = client.Get<List<ResDTO>>(new ReqDto());
Which is something the client/consumer of your service needs to know about. If you had the marker on the DTO the response type is already known.
The IReturn<> marker is also used to determine the Response DTO that's used in the HTTP Responses in ServiceStack's /metadata pages.
As far as I know, this is just a convenient way of defining your request/response DTOs.
You're free to use it, or not.
In the case where you define your DTOs in a portable class library, you won't be able to use IReturn. Perhaps IReturn should be defined in a PCL in ServiceStack. Just a thought.
if you have an entity which is reference in the client and a webservice like this
public class Post
{
public int ID {get; set;}
string Data {get; set;}
}
public class MyService: System.Web.Services.WebService
{
[WebMethod]
public int Write (Post post)
{
//Do stuff
}
}
on the client in order to use the entity you to instantiate from the proxy class
public void ClientMethod()
{
var post = new proxyclass.Post();
//fill post
new ProxyClass.Myservice().Write(post)
}
how can i use my domain entity to call the webservice?
public void ClientMethod()
{
var post = new Post();
//fill post
new ProxyClass.Myservice().Write(post)
}
Basically, you can't - with regular web-services, at least... the proxy class is completely separate. However, the above is possible with WCF, where you don't actually need proxy classes at all (however, for SOA purity it is a good idea to use them).
You could use reflection (etc) to copy the properties between your domain entities and the proxies, but it is quite hard to get this 100% right (although xml serialization should work [in theory] as an intermediate language).
So; if you want to use assembly sharing; consider using WCF, which supports this ;-p
To get hold of a service without using a proxy layer, you can do tricks like:
public class WcfClient<T> : ClientBase<T> where T : class
{
public T Service { get { return base.Channel; } }
}
(this will access the default configuration from the app.config; for more control you need to add a few constructor overloads matching to the base constructor overloads)
Then:
interface IFoo {void Bar();}
...
using(WcfClient<IFoo> client = new WcfClient<IFoo>()) {
client.Service.Bar();
}
I suspect that one of these might answer your qestion. The common theme is wsdl.exe /sharetypes and svcutil /reference.
Managing 2 web references with shared class dependency in a .NET project
Force .NET webservice to use local object class, not proxy class
.Net Consuming Web Service: Identical types in two different services
How to get a webserice to serialize/deserialize the same type in .net
.NET SOAP Common types
wsdl.exe /sharetypes
You should use WCF for new development whenever possible.
However, you should reconsider your reasons for wanting to use your domain class on the client. It does violate the principles of SOA by exposing to the client some details of the implementation of the service. Why should the client know anything about your entity classes, beyond the data that they contain?
For instance, your entity classes may contain methods to save the entity to the database. Why does your client need access to that method?
Also, one of the principals of SOA is to interoperate with different platforms. As soon as you require your client to use your (.NET) entity, you prevent a Java or PHP client from being written to use your service.
You may have good enough reasons to overcome such objections, but I recommend that you think it through and make sure your reasons are good enough.
For cases like this you're better to use json for sending and receiving data to and from web service.
Newtonsoft.json is the best json serializer for .Net. so you should change your Write method like below:
public void ClientMethod()
{
var post = new Post();
//fill post
new ProxyClass.Myservice().Write(JsonConvert.SerializeObject(post))
}