I am thinking about Implementing an admin subdomain - for testing purpouses on the localhost.
I've been thinking, and it Would be preferable if the subdomain had its own set of controllers in different folder (f.e. Controllers/SUBDOMAIN_NAME/newHomeController.cs) or that it would be different part of the web working with the same models and database.
Everything I have read so far included quite big code of, for me as a newbie, magical routing, often leaving the link creating, so much needed in views, unanswered.
Other way I have heard of is to develope it as another project, but that doesnt seem to be the way to go, especially if I want it to be at least a part of the project (same models and db).
I can imagine I am not the first doing that and that this might be VERY common intension so I hope there might be a SIMPLE way to do it (including creating links in view)
I would appreciate any insight into a complete solution of this "problem".
Related
We are looking to build multiple custom websites for different customer contracts, with tailored functionality, but all around the same theme and concept.
There will be about 70% commonality in functionality across all websites, but enough difference that building a CMS is a bad choice. Also customers dont want their DB to have properties that are not relevant to them.
The DB tables will be mostly the same, with a few different properties in each table per site. ie a customer table might be 80% the same, but in one project in might also ask for hair-color, eye-color, etc. whereas in another in might also ask for height and weight....
I'm ok with my other layers, but what is the best practise for the MVC presentation layer?
I want to create as many inherited functions/controllers/actions/resx/etc as possible via base classes (which will be the same project referenced by each website), but MVC does not seem to lend itself as well to this as webforms.
Any thoughts would be really appreciated, thanks
I would focus my efforts on the web config and building my presentation layer around config settings stored at server side. Also, I'm not entirely sure how logically different your pages will be, but having different CSS styles can dramatically change the look of your websites. This post was kinda vague, I hope I helped spurn some ideas...
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.
How time consuming is it to move a website built using Webforms to one built using MVC?
I have an existing website built using asp.net webforms, but it is a little annoying. I want to use lots of javascript and ajax, but webforms makes this a little difficult. It tries to do too much for me, and thus makes it difficult to work with when I want to do things it doesn't expect.
As such, I've taken to only using the Page_Load event, and totally ignoring all the postback stuff - when I need to deal with submitting forms, I handle it manually from the Page_Load event with Request.Form["ElementName"], but most of the time I use javascript.
I've heard that asp.net MVC is much nicer to work with, so I'm thinking of porting my site over to this. Given that I am writing runat="server" only on standard HTML elements that I need to fill with data with .innerHTML =, how long will it take me to move over to MVC? Or is it a totally stupid idea to attempt this move?
well, as you've probably guessed, it's such a broad ranging question that it would be almost impossible to give advice on your individual scenario without seeing the scale of the existing codebase. However, there are many mitigating factors that you may want to think of regarding moving functionality across piecemeal, such as:
can I break down the existing functionality into discreet segments
does the exisiting site still require all current features
are there new features that I could introduce purely in mvc
do i need to extend the object model - EF code-first may give huge advantage via mvcscaffolding
the beauty with asp.net is that you can mix-match webforms and mvc together, thus you can chip away at functionality as required. Of course, there are so many resources on mvc on the web now, it'll be easy to get going quickly, so i'm sure you'll make good progress.
I think you'll really enjoy mvc - it's a no going back experience.
[edit] - there are a few interesting resources on the web that discuss the mix of webforms and mvc. however, the definitive one for me has to be scott hanselmans from a wee while back. still relevent in mvc3 as it was then:
http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
also:
http://www.aspnetmvcninja.com/general/mixing-asp-net-mvc-and-webforms
Short answer, impossible to tell here.
Long answer, it depends...
It depends on how many sites you have to rewrite, complexity of the site and your architecture.
If all your logic is in the code behind files you will have a long walk.
If your architecture separates responsibility with use of services and abstraction, a lot easier.
If I should walk that walk, I would look into porting the code bit by bit. I've done this with JSF and Spring MVC, and it looks like this is doable with .Net too.
http://weblogs.asp.net/rajbk/archive/2010/05/11/running-asp-net-webforms-and-asp-net-mvc-side-by-side.aspx
Wanting to improve your code and your skills is never a stupid move!
It is possible to use them both within the same application. It isn't necessarily advisable, but if you set an MVC project up, you can tell it to ignore page requests that map to your webform pages.
You can then start moving over functionality as you need it.
If there is likely to be functionality you need to be available across MVC and webform pages, then this is going to get complicated and you are probably best moving to MVC in one go.
Personally, what ever you do, start small and straightforward and if you can bit by bit.
It would have to be a rewrite, not a port. MVC sites are built very differently from WebForms sites.
MVC is not based on the ASP.NET request lifecycle. There is no codebehind; business logic gets called from Controller classes; data is encapsulated in Models which are then passed to Views. It's a totally different beast from ASP.NET.
And be warned: once you've made the switch to MVC, you'll never go back to the old world of ASP.NET! :-)
Good luck!
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.