Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to build a c# spa application using angular with real-time messaging signal-r. The signal-r should read the data continuously from a data source and publish the updated data to the user and store the data in a database as well. It should also enable the chatting of the users.The expected number of users is around a hundred.
For such application what should be the best architectural structure of the solution? Should I implement two (three?) projects, e.g. one for the web app and the other for the signal-r, running as two applications? Then, in this case, how can I do the messaging between the applications? Or should I implement a single project for all of these? It would be best if you can provide the pros and cons of these alternatives or provide any other option.
Start with one project.
For 100 simultaneous users, you aren't even close to worried about load. Any simple hosting plan would take care of it easily. If you get more, ASP.NET and SignalR work just fine behind a load balancer (though certain operations can get more complicated).
A properly architected application won't be difficult to split into multiple processes in the future if it ever came to that, and doing so now is just adding mounds of complexity for no appreciable benefit. This goes double since it sounds like you are just starting out.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been reading about using azure for asp.net solutions and I am sold. I have questions about a ton of stuff but I would like to know how to scale a layered application. I read in a book that we could for performance and scaling sake we can have our models, business logic and DbContext in a separate project and that this project can be on a separate server. So I guess my question is can a .NET class library be hosted in IIS? how would doing this scale and give me an advantage. Sorry I am an advanced beginner so you will need to bear with me. Thanks
You can't host just a class library technically.
Having them in a separate project is not done for scaling reasons. It's done so you can reuse the models in unit tests etc.
One thing you can do of course is to create an API project, which will be hosted in e.g. Azure App Service. Then you can build an MVC project that then uses this API through HttpClient and the like. This separates your front-end and back-end allowing both apps to scale independently depending on their load. This would of course require them to be in separate App Service Plans in Azure as otherwise they share the server instances. The plan can be changed later though, so you can move them to a separate plan later and start with a common one for now.
If you want to break down your app into even smaller pieces, I would advise looking into microservices architecture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have written a windows form app in C#, but I want to turn it into native code for ASP.NET so I can build a webapp around it. However, I've never used ASP.NET and I'm not sure how to approach this. I've looked around and seen libraries such as VisualJS.Net, but it looks confusing and I'm not sure if I can seamlessly integrate it into my app without causing problems later on. Could someone lead me towards the right direction?
Thanks!
So if I well understand, you would like to "transform" a Windows Forms app into a ASP.NET. The problem with this approach, is that those two technologies are like day and night. They don't have the same lifecycle at all. Windows applications are by definition stateful. This means that they keep their state in memory and they don't need to rebuild it often (maybe at the loading of a file). Web applications however are completely stateless. The server receives a request, processes it and returns web content (HTML, JSON and whatever is needed). If the server is again contacted with new information, the state must be rebuilt (with the help of cookies, sessions, etc).*
However, what you can do the ease those problems is the following. If you separate your concerns, you can more easily reuse your business logic and your data and just re-code the view of your application. This means that you must separate what belongs to a View technology (WinForms, ASP.NET) from the model itself. There are numerous patterns to support this : MVC, MVP, MVVM. Respecting GRASP patterns also helps.
With that in mind, you could have three solutions : One containing your common code, one containing the logic that belongs to WinForms and another one that contains your ASP.NET logic. It's easier said than done, but this should be the way to go.
You can't turn an apple into an orange. Those two technologies are so different, that you will be better off rewriting the application from scratch, and taking advantage of all the goodies available in ASP.Net MVC 5.
Technically speaking one could devise some type of a converter, but it would potentially promote bad coding practices, something you should avoid.
Start learning MVC 5, you will be better off in the end.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to build software for property management, which includes full accounting support, document storage, client data handling and mail merge functionality.
I want to work with the smallest arsenal of tools that I'll need for the job - the simpler the better! It won't be graphics-intensive and support for multimedia is not required, but I would really like remote access.
95% of usage will be by property managers through their local desktop installations.
5% will be by owners, who want to check their account balance online, and change their personal details in the DB. There can be no installation for this.
Will asp.net suffice for this 5% remote access?
I only have a small amount of experience with winforms, and could learn asp.net if that's what I need for the remote access. My question is: Will this be enough for my objectives, or am I going to kick myself halfway through for not using something else? (WPF, Silverlight etc)
Thank you. I did ask this https://stackoverflow.com/questions/22628436/c-sharp-property-management-database-software-should-i-use-wpf-winforms-or-si earlier but didn't receive satisfactory results, and have changed my question slightly.
EDIT:
By data processing I mean running functions like "charge all 2,000 owners in the system a management fee increase of 5%" or "process all creditor payments into a batch banking file".
First of all, don't go for WinForms and Silverlight,
WPF is much more useful than WinForms
likewise ASP.net or ASP.net MVC based applications are more useful than Silverlight based web applications. And if you are planning to go for a web based solution, choose ASP.net MVC.
Now, concerning your decision to choose between desktop and web based solutions, I would personally suggest to go for a web based solution if there is no specific requirement which holds you going online. Also Google on pros and cons of web and desktop applications and this link.
And if you find out that a desktop application suits you, then develop it in WPF not in WinForms.
:)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm not sure if I'm going to be able to explain it right since I'm quite sure I don't know the correct terminology involved with it, which is also why I'm having a difficult time Googling for answers.
Essentially, I'm looking to develop a program that serves as a web site. It'll run constantly (like a service) and will return HTML when an outside user sends an HTTP request thru a browser or similar to a specific port on the computer this program runs on. Basically, this program will perform various background errands throughout the day but I want to be able to expose a web front end (almost like how you would with standard WinForms, but I want to be able to access it remotely) to be able to configure it, check the status of tasks, and otherwise interact with it.
I'm looking to use .Net, but I'm open to using something more universal like Java too. Someone with experience in this area would be helpful to explain any pain points you've encountered and suggestions on how to get started.
You can do it in C# with the HttpListener class.
I published an example some time back. See A Simple Http Server.
Although you might consider whether you really want to operate at that low level. I have written a fairly complex server based on HttpListener, and if I had it to do over again I'd probably just bite the bullet and use ASP.NET. There is a bit of a learning curve, but unless your server is incredibly small and simple, an ASP.NET application will be a lot easier to write and will likely be more robust.
Here is a simple example on how to do it in C# using the HttpServer class:
http://www.codeproject.com/Articles/137979/Simple-HTTP-Server-in-C
You are doing at least 2 different things, so you should probably create a Solution in Visual Studio.NET with one project for each purpose (You can have many projects in a solution), probably with at least one Data Access project as well (of type Class Library). If the solution does things at certain times of the day, then those can be Console Applications that run through task scheduler, rather than one of more services. Services are better suited to things other than simple scheduled tasks. A Web Application project can serve up your html.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I would like input on the design I currently have planned.
Basically, I have some number of external instrumentation, each of which should always be running, collecting specific data. My thought was to create a service for each, always running and polling the instruments, performing logging, etc. There could be one instrument, or there could be 40.
However, I need one application to consume all this data, run some math on it, and do the charting, display, emailing, etc. The kicker is that even if this application is not running, the services should constantly be consuming data. Also, these services should almost always be supposed to run on the same machines as the client application itself, but the ability to network them (like .NET Remoting used to do) could be an interesting feature.
My question is... is this the best design? If it is, how do I go about doing the communication between services and application? I've looked into WCF, but it seems to be geared towards request-response web services, not something that is continually streaming data to anything that might listen to it. Alternatively, should I have these services contact some other Web Service using WCF, that then compiles the data for use in a thin client viewer that polls the web service often?
Any links and resources would be greatly appreciated. .NET namespaces for me to research are also appreciated. If I wasn't clear about something let me know.
Just a thought....but have you considered perhaps adding a backend database? All services could collate data and persist it then your application that needs to process the information can just query the database rather than setting up loads of IPC between the services.
WCF can handle streaming. It can also use MSMQ as a transport, which will ensure that no messages are lost, even if your instruments begin producing large quantities of data.