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.
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 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.
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 6 years ago.
Improve this question
I'm asking this just to see experiences from others.
For most of the cases having ASP MVC web site is an overhead. At least for me it's much cleaner and easier to have WebAPI which responds with JSON and then you can attach either SPA application or Mobile app or whatever.
I have a feeling that if you are using ASP MVC controllers will not be controllers, but controllers full of the if conditions and some session bags which are hanging around. Views are combination of HTML and Razor which in most cases looks really ugly and full of "TODOs" ;)
I can understand if it's used in older projects and now we just need to maintain them. But when you are starting a new one, why you would choose ASP.NET MVC or any other similar framework?
In my opinion, it is all about your expectations - if you need REST you should take WebAPI of course, but in case of RPC Style Actions requirements in your project, MVC will be better choice
It depends on the resources available. If you have a team already that is doing all pure UI (all request/response to the backend is via a RESTful API), then you can have those team create the UI for you and you can focus on the API. These UI applications are mostly client-facing products.
But sometimes in your team there is a need to develop in-house or internal applications such admin/operations applications, and the UI requirement is not as sophisticated , the teams skillset is not heavy on UI, and there is a need to develop the application ASAP, then I would go with MVC.
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 7 years ago.
Improve this question
I have an Asp.net MVC project that includes three management systems:
1.Car rental system
2.Bus ticketing system
3.Home delivery system
Each system should have different types of modules and each module deserves an area of its own.How should i manage the project. Should I create three different projects for
car rental,bus ticketing, home delivery system and create nested area to manage their own modules.I also want to maintain generic repository pattern,unit testing.
For asp.net MVC you can create one core MVC project that include (add reference) in other project that project contain your Car, Bus and Home areas.
You can create a main web project for your application with three areas for three modules.
And you can create three class libraries for three different businesses.
So, if you need to change any business logic, you just go to the particular dll and made changes. (ex. go to MyWebApp.Service.Car and update and compile the dll and update this dll to your production site to update the business logic for the car rental system)
Please feel free to ask any doubts on this...
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 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 8 years ago.
Improve this question
We currently have a single database with users, customers, products and orders logically separated by schemas. We then have several MVC.net applications accessing the database via their own BLLs. Each of these applications have their own functionality and share some aspects with some/all of the other applications.
Currently, some code is duplicated in these BLLs and it's a bit of a mess to maintain. It does however, allow us to develop features quickly and deploy each application independently (assuming on major database work here).
We have started to develop a single access layer, properly separated out that sits above the database and is used by all of our MVC.net applications. Logically this makes sense as we can now share code between our applications. For example, application A can retrieve a customer record in the same way as application B. The issue comes when we want to deploy an application, we wouldn't be able to deploy one application, we'd need to deploy them all.
What other architectural approaches could we consider that would allow us to share code between our applications and deploy those applications independently?
A common solution is to factor out services (based on an arbitrary communication layer REST, WCF, Message Bus, your choice with versioning) and deploy these services to your infrastructure as standalone services.
Now you can evolve, scale and deploy your services independently of the consumers. Instead of deploying all applications you now only have to deploy the changed services (side-by-side with the old ones) and the new application.
This adds quite a lot of complexity around service versioning, configuration management, integration testing, a little communication overhead etc. So you have to balance the pros and cons. There are quite a bunch of articles on the net how to build such an architecture.