I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.
We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.
At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.
After rambling a bit, here are some specific questions:
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.
Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?
Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?
Thanks for the time. I do appreciate it!
ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:
URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.
URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.
Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.
As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?
Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render.
You have testabillity.
Thats all great: read here about it
link so
But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.
Related
I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).
I'm looking for best practices and good ideas rather than a proper solution.
scenario: I work in a web agency and thus we are plenty of websites from several customers. They're built upon a cms we made, so websites are quite identical for the 90% of code. However, remaining 10% struggles me and my team as it involves not only the presentation layer but behavioral logics too (ex: a website1 requires simply user/pass registration while website2 needs more data, facebook connector, etc. But this is a very easy example).
Making ad hoc development for our customers is becoming painful as keep each version aligned is getting really hard for us
What I really dream to have is an extendible website that works by itself, but in which I can override a part. This behavior should sound like "look for the specific part, if it doesn't exists get the base one". The parts could be a method, a class, a page, a control, a static file.
example:
Suppose I want website2 to have an own login component, let's so imagine that we have a situation like:
/website_base
|_ login.aspx
/website1
/website2
|_ login.aspx
So, if I ask for www.website1.com I'll get /website_base/login.aspx, but if I ask for www.website2.com I'll get /website2/login.aspx
Any idea?
Thanks
PS: we work with asp.net 3.5 framework.
There are couple of ways to achieve this.
Approach 1:
1. Split the common functionality in modules and create a pluggable structure. (like DotNetNuke) Obviously this will be more time consuming initially but over the period of time it can make itself like a product.
Approach 2:
Firstly - I would create separate solution for each client for better maintainability. This will save me a lot of hassle while maintaining the source control and when one client comes back with issues and we have multiple releases for a single client.
Secondly - From my core solution, I will identify most commonly used artifacts for each layers and move them to a core assembly.
a. For example – In UI you can use themes to give different looks for each client. Have a default master page which comes with the core site structure. All client specific details like Logo, name, contact details etc… can be configured using some DB fields.
b. In Business Layer and Data Access Layer – core functionalities like Membership, Logging, CMS related Entities etc I would have as a dll
i. I will derive my client specific logic from these core classes.
Last but not the least – how you deploy your code and how your IIS VD structure looks like… I believe it will be totally dependent on how the solution is packaged.. I would create a deployment package for each client which will give them the ability to deploy it to any server wherever they want until you have specific issues about proprietary software hosting.
Look into ASP.NET MVC. It is much more extensible than Web Forms, can be integrated into your existing Web Forms application, and it is very easy to build reusable custom components like what you are describing.
Otherwise, I would suggest looking into WebParts and developing reusable custom server controls for the components that you need. This way you can encapsulate the complex functionality within a single UI control without having to write repetitive code. WebParts are also compatible with Personalization, which you can leverage to manage the variance between which sites use which controls.
I definitely recommend MVC as the way to go for building extensible .NET web applications, but learning a new technology always incurs a cost in the time it takes to understand the new paradigm. I hope this helps you.
I found a smart solution here: http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx
Check it out
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away
Has anyone successfully used a CMS developed for standard ASP.NET with ASP.NET MVC?
I currently use Immediacy CMS and it seems to be quite tightly coupled with standard ASP.NET, but I'd really like to start using ASP.NET MVC.
Are there any CMS systems out there directed at MVC?
How could I persuade my employer to move to ASP.NET MVC?
I suggest take a look to Kooboo (kooboo.com), a simple to use but powerful for developers. Well documented API and based upon ASP.NET MVC (of course ;-)
N2 CMS has an example site in ASP.NET MVC that I've been playing around with that works quite nicely - note that the code is now hosted on Google Code.
The problem you've got is that many CMS' already do a lot of "routing" in that the pages you are requesting/editing don't actually exist on disk, but are all in a data store of some kind, and there's an HttpHandler or ISAPI Filter sitting in front of ASP.NET to intercept the requests and work out what should be happening.
I have not personally seen any of the big name CMS systems out there upgraded yet to take advantage of many of the new things the .NET framework offers, let alone start working on the MVC framework.
As with all things, a cost-benefit analysis is the best way to convince your boss to do anything. If you can point how how moving towards the MVC framework is going to make some immediate positives (as well as many long term positives) that can outweigh the costs (in time, energy, and money) in the switchover, then you have succeeded.
ASP.NET and ASP.NET MVC are very different beasts in terms of how you develop applications on top of them. Technically, an ASP.NET MVC application is an ASP.NET application with some generic handler that invokes the core MVC framework.
The ASP.NET MVC framework is also relatively new (1.0 just released last MIX) and so it'll take a while before becoming mainstream.
How you can persuade your boss? Talk to him about the positive sides of ASP.NET MVC, and how it will improve his future business. There's plenty of material available to demonstrate that.
I do a lot of work using Immediacy (I used to work there) and I had thought about doing the same thing a couple of months ago. I think that the main issues would result from things like the plug-in handler, the idoc handler and (if your still using it) the ilink hander.
When you enable things like friendly URLS I think this would cause issues if you had similar named methods in your controller actions.
You may be able use some MVC in your project, I could see it working as an admin add-in but I couldn't see it being used to usefully in the main webroot.
I would think a CMS would have to be built using MVC in mind to get the most benefits from using the pattern, instead of trying to make it work in parallel with a pre-existing system API (limited as it is) and making more work for yourself.