Even though ASP.NET Boilerplate does not seem to support Blazor, is there any reason you could not use it instead of the MVC/Angular frontend and just consume the REST services provided in the ASP.NET Boilerplate Service Layer? Or are there better alternatives for that setup?
Thanks.
Related
I know some basic concepts about SOA. But I don't know how I can develop a project based on SOA. So, I want to know a way for implementing SOA in Asp.NET Web API project.
SOA is not a technology but a style of design/Architecture. There are different implementations of this. They are as follows.
Web services based on WSDL and SOAP
Messaging, e.g., with ActiveMQ, JMS, RabbitMQ
RESTful HTTP, with Representational state transfer (REST) constituting its own constraints-based architectural style
OPC-UA
WCF (Microsoft's implementation of Web services, forming a part of WCF)
Apache Thrift
SORCER
ASP.Net Core supports REST api and if you looking at implementing SOAP based service using asp.net core here is a handy link for this
https://stackify.com/soap-net-core/
There are many videos on youtube and there are many websites to learn REST services. If you are familiar with c# and asp.net, you can start learn ASP.NET Core to build your restful services.
Here is a link to one video links.
In upgrading an old project that was built using WCF Web API to now use ASP.NET Web API, I have run into a few classes that implement HttpOperationHandler<HttpRequestMessage, T>. I'm unable to find an equivalent class in the new assemblies. Does something similar exist or will I need a different approach?
The concept of Operation handlers has been replaced with Filters and model binders.
Here are some links that you might find useful:
How to Migrate from WCF Web API to ASP.NET Web API
Mike's blog on How WebAPI does Parameter Binding
Getting started tutorials on ASP.NET WebAPI page.
Hope this helps.
I have a working ServiceStack application which started off part of my MVC application which contains my Jquery Mobile web site.
The services are growing and I am thinking about moving the ServiceStack code to separate app but not sure whether I should host service stack in an Asp.net web application or in a MVC application.
Are there any benefits down the road if I go one way or the other? In the future I need to introduce authentication for the services, would that be a factor in deciding?
I would host it on an vanilla ASP.NET host, since it's a more barebones web host than MVC which adds additional (and un-necessary) HTTP Modules and overhead.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))
I want to use WCF RIA Services as the middle tier for multiple clients including Silverlight and ASP.NET MVC.
I created a solution with Domain classes in a separate assembly using WCF RIA Services 4.2 CTP and Database First, which I want to share between the Silverlight and MVC clients. The solution looks like this:
Solution Foo
Foo.RIAServices.Server.Entities
Foo.RIAServices.Server.Entities
Foo.RIAServices.Server.Entities.Web
Foo.RIAServices.Client
Foo.RIAServices.Client.Web
FooMvcApplication
FooMvcApplication.Tests
FooResources
What if anything is wrong with my architecture and approach? Is there a better approach to using the Microsoft Entity Framework to create a common service for multiple clients?
Can I create a common custom Authentication service for both? Will the [EnableClientAccess()] and [RequiresAuthorization] decorations be respected for all clients?