This is a theoric question about how to organize web service.
Building a web service using ASP.NET Web API you can create a lot of controllers and web methods inside them. However, maintaining many controllers and methods in the same solution can be hard.
What are the criteria that shuold be used in order to choose to split a solution in two or more?
What advantages and disadvantages derives from using a single solution with many methods and controllers and the advantages and disadvantages of using many solutions ?
I guess first question will be: what is the number are you talking about with "a lot of controllers"?
The main disadvantage I see when dealing with huge solution is load (CPU? RAM, Resharper caching). I do remember I had a solution of 54 project and it building takes over 3 minute. So we had to extract one small solution for development and full solution was loading only on integration of our part. (Well SSD probably helps here)
But also it is semantics. The best way on my opinion is making separation based on complete blocks for example you extract interface and then it implementation goes to another solution or project.
Related
I was looking through my companies web application that was developed in .NET 2.0.
On deployment they have nested web application created under "default web site" as in the structure below
Default Web Site
My Root Application
Sub Application 1
Sub Application 2
Sub Application 3
Every application is a .cs project. Many of the sub applications are even just having a single web service(approx. 15-20 web methods) and nothing more.
As the guys who developed this project are not around I was wondering
Q1. what was the reason to take this approach? Was there some limitation on IIS and .NET 2.0 that made them have this structure.
Q2. If I wanted to merge all of them into one single web application. Is it recommended?
Q3. What are the advantages and disadvantages of such web application nesting? when to nest web app and when not to?
I am sorry If this post is appears in the wrong section of stack overflow. If so please guide me in posting it in the right section.
Thanks in advance for all the help and suggestions.
The question is quite broad, without knowing, what are those sub-applications, how, or if, they communicate with each other, and so on. But splitting things apart is usually a good practice. In your particular case: the sub-applications can be better scaled, when you run them on several machines. You get even better maintenance, as if you have to fix something, you deal then with some discrete part of your big application. The architecture should be much better, as when it was possible to split the applications into several sub-application, it means, they are loosely coupled.
In our web applications, we always have usually 3 Web-Projects: API, Web, CMS. I'm not counting here other Business Logic Layers, DAL, etc. So now, we can run them as separate instances, as you have, but we can also run them as one application, we must just specify the routings: API myapp.example/api/**, CMS: myapp.example/cms/** and Web: myapp.example/**.
I am working on a Restful WCF API. I figured out it would be nice to have one service contract for API related to Users (IUserService) and then for example another one for Posts that users add to the database (IPostService). This approach makes it easier to read the code , as well as to collaborate on the code, since several people can work on separate files.
However, this way, to make a requests I would have to call <url>/UserService.svc/user/123 to get a user and <url>/PostService.svc/post/456 to get a post.
Is this a viable solution , or should I have just one service for a case like this ? If yes, is there a way how to make it easier to collaborate and read the code ? Maybe with partial classes?
I don't have much experience with theses technologies and C# in general, so I will appreciate any help :)
Thanks.
Your solution is definitely viable. And even more scalable if needed in the future than the partial classes solutions. By having the ability to split completly in multiple specialized services.
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.
I have built and application in ASP.NET MVC, which started out orignally as a way to learn the technology. However, the application (and my knowledge of MVC) have progressed and I would like to use parts of the functionality I have created in other applications. Eg I would have 2 websites both wanting to use the same News Control (CRUD) model and controller methods, but with their own unique Views. I suppose my questions are:
1. Is this going against the principles of MVC?
2. What is the best way to achieve this?
3. Is there a "best practise" way to re-use my exisiting functionality?
Thanks in advance for any answers.
Depending on your exact requirements I'd recommend you take a look at Rob Ashton's series on multi-tenancy in ASP.Net MVC, and also the portable areas part of MVC Contrib.
You could setup a Visual Studio solution in which you would have a common class library project containing models, controllers and data access and two web applications containing only the views and CSS of the two sites both referencing the same controllers and models.
Hopefully most of your logic is already separated out, but you can also pull your controllers out to a separate assembly, I believe:
http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx
Reuse is a really central part to the concept of MVC. It's very common in production MVC sites to have a separate assembly (or assemblies) for the Model. It's somewhat less common (but still done) to do the same for Controllers. The S#harp architecture project (for example) uses a separate assembly for everything, leaving just views, content, and global.asax in the Web assembly. It's all good.
Another thing you might consider is the use of Areas, which are like mini-MVC apps that you can reference in your 'main' app. It's a great way to package reusable pieces like you describe.
Paul