How to structure a SignalR core project for an enterprise application?
An application that has a lot of functionalities as so a lot of classes and methods to invoke.
Multiple hubs for different areas?
Only one hub that dispatch to different classes?
How to arrange the project folders?
I can't find any viable example over the simple tutorials?
Any suggestions?
I'm afraid that this question will be closed because it is not to a specific problem but I will put my suggestion.
Since you will do a lot with SignalR and it would need to resolve different specific problems I would recommend to create a .NET Core Web Application to connect your product with this service using SignalR. You should start first reading this SignalR documentation.
So you will have one app that is responsible to handle those connections and your app must have various hubs for different business logic. Create interfaces and managers that can be shared between hubs and inject the HubContext in the managers to call methods to the clients.
Since you mentioned enterprise application I would extremely recommend you to look at Azure SignalR to manage and handle your connections.
Are you planning on using ASP.NET 4.x framework or .NET Core?
ASP.NET Documentation states that it makes no difference between single and multiple hubs from a performance standpoint. ASP.NET Docs
That does not mean you may not have performance issues overall, that will highly depend on your design/implementation.
.NET Core does not appear to state either way. Core Docs
According to their GitHub repo, you can have multiple if you want. Understanding that one of the differences is that under .NET Core each hub will have its own client connection.
Related
Recently I built MEF WCF service, hosted on IIS 8, which receives the command, performs long background process with SAP ECC and Local DB, then returns the status. So user interface input and output is only the string.
In Internet there are many blog post about WCF Dead and that it's better to use WEB API, and in the future ASP.NET Core, which is even better...
My question is, is there the sense to update the project to ASP.Net Web Api or wait to ASP.Net Core, or it's better to use another technics for this type of work?
Having more people talking about a technology does not means another similar one is completely dead; as an example look here to find about incoming WCF implementation for .Net Core.
Of course, this is a subset, as for Web API, MVC or Entity Framework are not uspporting today all features that their Full 4.x versions do.
Short answer: you can keep you WCF implmentation and come back later.
Longuest answer: look at what features WCF for .NET Core contains (especially for bindings) to see if porting would be easy, or if you need alreday to tihnk about moving to something else.
I want to migrate my WCF services to Web API / MVC6.
Currently I have one application hosting multiple WCF web services (http://{ip}/{app}/Service{x}.svc/{vs_endpoint}). This model is pretty good, we can separate the public services from internal services and we have control over each service in particular, although they all are under one single application.
Would I be able to achieve similar thing in Web API / MVC6, having one project for multiple services? From my initial investigations I understood I would need to do something along these lines.
If yes, it would be nice to have some recommendations how to structure this project.
Also, can you share some pros and cons about one vs multiple projects to host these services?
Thank you in advance!
Yes you can achieve this by using either separate controllers or logically grouping controllers into areas.
Once you start programming you will automatically came to know that how it is possible and easier to do than wcf.
good luck...
I have an application which is built in ASP.Net WebForms and Silverlight.
There is another WCF services application which is accessed by silverlight part of my application.
Now I have to Re create the whole application in an MVC Single Page Application(SPA) and of course the WCF one because now I would need Web API for that.
An initial solution comes into mind is to add a web api project into wcf services application and start creating web methods there and call wcf methods from there if that functionality was already there.
And for webform start a new spa with mvc project from scratch and use durandal or any other spa client framework(hell of coding).
Any useful solution/advise? as I am looking for simplicity.
I searched around and found some questions but really did not helped as they are about merging with existing apps.
Note: application is a large application with a lot of functionalities
You have to decide how confident your team is with client side frameworks. Development of Single page applications may not be easy in the beginning, but you will get used to it very quickly. It's very important to give your team the right training.
In my opinion, Durandal is the simpliest, most elegant and complete framework to build enterprise level SPAs. It is important to know how knockout, requre and durandal's router and composition work. For data centric application I would use breezejs to manipulate and cache data on the client side and request it from the server side. Breeze works best with Entity Framework on the server side, but it's not necessary. If you can use Entity Framework, it will simplify your development, because it can generate metadata of your database structure for breeze. If Entity Framework is not an option, metadata can be written by hand.
I would make server side as thin as possible. Serving data from your database using web api with ORM of your choice and some cshtml pages.
Durandal Get Started is a good place to start.
Durandal Auth is a very good template for enterprise level SPA. It may not suit you completely, but you can use it as a guidance to build different modules of your application.
Breeze samples I suggest you consider using breeze. There are good courses available on pluralsight.
Knockoutjs has good training on data-binding.
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.