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/**.
Related
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
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.
Looking for suggestions regarding an upcoming project that I am involved in which revolves around adding certain functionality to an existing ASP.NET application running on IIS 6.0 programmed in VB.NET.
To aid in future development the client wants the additional functionality to be as future proof as possible. Ideally I have said that I would like to push for a solution using ASP.NET MVC3, running off IIs 7.5 and .NET 4, written in C#. This solution would act as a seamless addition to the current web-portal appearing probably just as an extra tabbed page.
But they will be completely separate web-apps. Which is crucial.
The main problems I can foresee are firstly sharing session particulars between the asp.net web app and the new application. Particularly with regard to maintaining session state (and not having IIS timing out on one of the apps). Also, conjoining the two "apps" appears problematic in my head, although this may be far simpler than I fear.
I'm asking for suggestions for these two problems if anyone has any ideas please say!
So far I've come up with the following solutions be they terrible or not:
1) Embed the new functionality into the existing codebase (not a great option). This would mean losing any potential future upgrade-ability and also means not following better OO conventions by utilising the MVC framework.
2) Using an iFrame to link to the razor pages of a seperate MVC3 app (the one I'm favouring currently). Allows uses of all new technologies, however downside is sharing session data. Either through iFrame "attributes" (is this possible?) through persisting a session state to a db? (slow?) or even some kind of web service interaction between the applications to push/pull user/session data?
Any advice/suggestions greatly appreciated!
I agree with you that C# and MVC is the "way to go", but unfortunately mixing two applications together is going to give you a whole bunch of headaches, not least the different session IDs. You'd probably have to have a shared database table to map them together and, as you can probably imagine already this reeks of "Band-aid".
What are the ramifications in rebuilding what is existing, in to C#? Perhaps you could suggest a complete upgrade. The client themselves seem to extol the virtues of future-proofing and therefore this would be the way to go. And no, I wouldn't promote the use of a "code-converter", but it really shouldn't be that difficult.
The next thing to consider, I guess, is "future-proof". Is the client worried that VB.NET is going to disappear any-time soon or that it cannot handle anything in the future? I find that a very unlikely scenario, honestly.
I think I've waffled on a bit, but essentially combining two applications, one with old and one with new functionality will cause a headaches. This could be solved by migrating the old site to C#/MVC, and then adding the extra functionality. True, this may seem like a large commitment today - but further on down the road, it will pay dividends.
If the current site can be upgrade to .NET 4.0 there's no reason why you wouldn't extend the existing application.
There's nothing to stop you mixing MVC and web forms (indeed there are several articles on how to do just this). There's nothing to stop you mixing VB.NET and C# (or, so far as I'm aware, to stop you doing MVC in VB.NET).
You'd have to work very hard to convince me of the merits of using iFrames. Very hard. You might be able to persuade me of the merits of running two applications side by side - with the functionality split by folder - but to be honest I'd be much happier upgrading the existing site and then building from there.
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.
Currently I'm working with a big, old and extremely poorly written ASP.NET 1.1 application and the continuous maintenance is becoming quite a problem. Basically it's reaching breaking point and I'm reluctant to expand it any more than I have to as demanded by the business. Based on my experience creating other projects from scratch it would really suit an ASP.NET MVC based solution. Oh how I wish the world were that simple...
The fact is that I just cannot justify re-writing it from scratch and the business cannot afford it. The ideal solution would be to start writing an MVC-based application alongside it and begin a slow migration as new requirements arise.
I've read posts which state that this is entirely possible, but in my experiments I've not found it so easy. The current application contains several large data access and business logic layers shared by other applications that the company produces. These are also written in 1.1 and will not compile in 2.0 (and would destroy the other projects if I tried!) so I cannot upgrade them. Since I can't do that I'm stuck with an application that cannot even be opened in a .NET 3.5 capable visual studio. The new MVC app would also have to make use of these layers.
I am entirely open to suggestions. I'm desperate to find a solution that I can quickly demonstrate would allow me to improve the product immensely without taking too much time or affecting the rest of the business.
You could write a WCF service on top of the existing business layer and have your new app talk to that service instead of referencing the business layer directly.
You need to divide to conquer. Analyse the current app and its layers and see if you find a way to divide each significant piece of functionality into a discrete area with as few changes as possible.
Then make each area a unique service using the old technology.
Then you can rewrite each service slowly as you can fit it in and not affect the whole.
Otherwise you are going to have to come up with a convincing business case for your managers so that they allocate you the time to do the job properly. Sometimes our job is political as well as technical.