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).
Let me explain first that I'm new to web development and it's not my area of interest. A few months ago I made a quick research of various web technologies and I decided that I will learn ASP.NET - Web Forms. This has been working out for me for a simple site - I like the master pages idea and the modularity idea supported by custom controls. I made a few custom controls that I surely wouldn't find on the internet.
Problems began when I started to look for a blog that I could elegantly integrate into my existing master page with my existing themes and styles. The best thing I could find was BlogEngine.NET. But it is designed as a standalone blogging system, not as a control (I just want to display the posts and comments). Isolating what I want from the code base and integrating it with my web app is going to take unknown amount of work and time.
So I turned towards CMS with a blog - Orchard looked very promising. Then I realised that integrating my own Web Forms into Orchard is almost an impossible task for me (definitely not something I have time for). What do I think is the problem here? The CMS is not providing reusable components for easy integration in the spirit of Web Forms - it locks me in - as long as I stick to what they offer I am safe, but once I want to integrate my own Web Form - it's a no go.
So, do you know any NET CMS that allows integration of third party web controls just like you would do without CMS? Or better still - is just a collection of isolated, reusable components?
I realize this is an old thread, but don't know if you ever got the info you needed. If you are OK with commercial software, you might consider SiteFinity (by Telerik) as it uses master pages to generate layout, and webforms user controls for custom code. If you are more in need of an open source/free product, you might consider looking at MojoPortal or CarrotCake CMS.
I have been working on ASP.NET MVC for a while and loving it so far. But I am hitting a wall now.
I am working on a new intranet site, where I will have to host many projects, ranging from couple of pages to full blown applications. I have been using Areas to differentiate between the projects. It's all good so far.
Now, the solution is too big and every simple change I need to compile the whole projects which consists of all the areas (multiple projects). I am always afraid of making changes to live once I compile and upload the dll.
Is there anyway that I can hold multiple projects sharing same layout but to compile each projects into separate dll?
Thanks in advance
EDIT
Thanks guys, I followed Portable Areas as an ASP.NET MVC Project and he seems to have explained things much easier in a step by step to get started.
Have you considered using Portable Areas feature in the MVCContrib? - read a post about it here
Also read the response from Eilon in another question Multiproject areas in ASP.Net MVC 3
If the portable area solution won't work for you then it's probably time for a refactor/restructure of your single web project into separate web projects. As it is an intranet site you'll probably want to setup some sub-domains to allow you run separate websites under the one domain.
Eg.
www.yourdomain.com
admin.yourdomain.com
calendar.yourdomain.com
etc.
This way you can segregate your functionality and update different areas of the intranet without affecting others. You may of course need to look into single sign-on across your sub-domains depending on your site.
I would normally extract all common functionality into a core project (class library) which may be used by all of the web projects, and keep each your web projects as lightweight as possible. Then you can create separate solutions for different web projects or groups of web projects.
Also consider looking into continuous integration/build server so that you can easily check if a change you make in one project is affecting other projects that may not be in your current solution.
We need to develop quite a powerful web application for an investment bank. The bank IT would like us to build it on top of the SharePoint platform, but we would prefer to do pure ASP.NET programming.
The web-app should have the following characteristics.
1) It will be a site for bank's clients that will allow them to view their stock portfolios, get miscellaneous reports with graphs and charts, etc.
2) The web-app will also allow clients to send orders to the bank to buy stocks and perform other financial operations.
3) The number of users will be approximately 3 000 000 (total) and 20 000 at any one time.
We have never made any SharePoint programming, but as far as I know, SharePoint is primarily designed to create intranet sites for colleagues to communicate with each other and work more efficiently, to maintain a document library, etc.
However, the bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
The question is: is it better to create our web-app on pure ASP.NET and deal with scalability and other issues ourselves, or base it on SharePoint - taking into account that the web-app we need to create is non-standard and complex?
Thank you,
Mikhail.
UPDATE
In the answers, someone suggested using ASP.NET MVC. My another question is: should we use "classic" ASP.NET or ASP.NET MVC for such project (if we leave out the SharePoint option)?
Do you need document management? Do you need version management? Do you need to create "sites"? Do you need audience filtering? Do you need ECM (fancy word for CMS), Do you need collaboration stuff on your site? If your answer is no then SharePoint is not for you.
You said "We have never made any SharePoint programming" and for that reason alone I think you should not use SharePoint. You also say that your app is going to be "non-standard" and complex, another reason not to use SharePoint.
Sounds like you know ASP.NET so I would advice to stick with ASP.NET or ASP.NET MVC.
Hope this helps
The answer is simple, you should go with what you know. If you prefer to do it in ASP.NET then, that is what you should go with. Trying to learn a new technology on that size of a project will almost certainty cause you severe problems when trying to develop it. Can sharepoint scale to that number of users, probably, but you don't know how to make it do that. That is the real key.
They are correct SharePoint does have a lot of functionality out of the box, but that doesn't mean that it will make you more efficient, because you don't know all of the APIs etc. to access.
Actually, if you want to know the way to cheat. If they force you into using it, you can run ASP.NET applications under SharePoint (well kind of). You can tell SharePoint to essentially ignore a path in the site and use regular ASP.NET as a web application just like any other site does. Really, this isn't using SharePoint, but it can get you out of a bind, in the "Needs to use SharePoint to make them happy scenario".
Mayo suggested contacting MS. I have a feeling they already have a relationship with the bank and have provided some insight about the project. I would contact: http://www.mindsharp.com/ and see if they can help you out. They are a training company, but I bet that the owners would be willing to help consult, and I haven't found anyone with more knowledge on SharePoint than Todd Bleeker.
I'll not go into the merits of sharepoint, but suffice it to say that I have been developing in sharepoint since it was known as "digital dashboard" - it was just a javascript-encrusted today page for outlook. With respect to its .NET incarnations, it has taken me about 3 years to become what some might call "expert" on SharePoint 2007/MOSS.
First up, let me give you some warnings concerning the politics of these kind of jobs. As a contractor, ALL of my jobs over the last 6 years - covering shaerpoint 2003 and 2007 - WITHOUT fail, have been getting about me on site with a client who has demanded sharepoint, and a development shop with decent ASP.NET developers who have become hopelessly lost and more than likely have blown 95% of the budget on the last 5% of the project because they have embarked on writing custom extensions to the platform without fully understanding the product.
If clients, and the shops who service them, spent more time understand the product and studied it to see how they could change/streamline their business processes & requirements slightly to suit sharepoint instead of being rigid in their specs (that were ALWAYS written with next to zero real experience of the platform) and deciding to get custom development done, then more sharepoint projects would be delivered on time and on budget. Sadly, this is not the case.
So, number one: SharePoint 2007 is an excellent product, but please, for the love of jeebus, find yourselves some top gun sharepoint developers who really understands the product before you embark on this journey. If you don't, you will all go down in flames.
-Oisin
What a load of CRAP that sharepoint isn't cut out for what the op wants to use it for. Especially the "Do not get yourself wrapped up in SharePoint" comment from ChaosPandion. Maybe he thought it to difficult and gave up...
Sure SharePoint development takes some getting used to, but it is able to what is wanted by the op most definately. SharePoint is built using ASP.NET so anything you do in ASP.NET can be used / ported to SharePoint. It is not a standalone product, but a DEVELOPMENT PLATFORM. It will scale to serve that many users, using multiple WFE's (Web Front Ends) and a SQL Cluster as backend.
The question here is: is sharepoint the most suited platform for building this site? Then I would have to answer, probably not, seeing as the wanted functionality is almost all custom development. If you plan on doing web content management as well, then yes, SharePoint is definately worth looking into. Also, SharePoint takes away all (or at least most :-D) authorisation and authentication wories. It is Department of Defense certified. And if the offered out of the box security is not enough, just write an authentication provider (seeing as SharePoint uses ASP.NET's provider model).
To answer your questions:
The bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
SharePoint is farm based, to which you can add machines, having each machine perform a different task, which means either app server, index server, WFE, document conversion services., WFE's can be behind a load balancer to distribute requests. Also I want to mention the web content management again.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
Like I said, SharePoint is based on ASP.NET, so it is as much customizable as ASP.NET is. You could even create an ASP.NET web site, put all UI in Controls and then use those is SharePoint, maybe even have the controls use it's own database. As for it being tedious, not really. It's just DIFFERENT and deployment / testing is not like normal deployment / testing. SharePoint uses so called solution files (.wsp files), to package up functionality and deploy it to the server. This IMHO makes it possible to deploy functionality in a very modular way. Furthermore, there are loads of cool open source projects out there that make sharepoint development much easier and also provide cool extensions to "pimp" your site and make it more fun and easy to use for end-users.
Nuff said....
SharePoint development can be tedious but I'd hardly say the platform cannot be easily customized. I recently began developing with it full time and so far, I impressed at it's flexibility and suitability for my application but my needs are quite different from what you've described.
I understand 2007 is a vast improvement over 2003 so perhaps your information is only outdated. I hear 2010 is going to again be a significant improvement.
It's your job to deliver the functionality that the customer desires. If they desire a SharePoint solution, unless there's some particular reason why SharePoint really is a weaker model, that's what you should be able to deliver. In the event that SharePoint isn't a good fit, you need to be able to explain why to the bank's satisfaction. I'm not convinced "We don't know SharePoint" is an acceptable response in this situation: the bank's inclination should, at that point, be to find someone who knows both technologies well enough to deliver a product in SharePoint or better explain why SharePoint isn't actually what they want.
UPDATE: After looking at this more I would add that I do not believe that SharePoint is for you. As I mention below SharePoint is for collaboration. If the users that come to the site require an isolated experience then SharePoint is more overhead than you need.
SharePoint is built on top of ASP.NET so you have everything that you want to do with ASP.NET in addition to what SharePoint provides. Anyone who says that it is difficult is trying to make it that way. You can deploy stand alone custom pages with 100% of your own code and it will run under sharepoint, or you can create new application pages that also contain any code you want to write, or you can simply add your own webparts that can be added to any page you choose with 100% of your own code.
Here is just one example.
Creating an Application Page in Windows SharePoint Services 3.0
What SharePoint offers on top of that is a whole different paradigm on collaboration tools. If you wish to leverage it (if not the cost on return is somewhat limited) you can build amazingly complex and integrated solutions that is build around the aggregation of data from across an enterprise.
That being said, do not go into it lightly. If deployed wrong or with a half understanding of where SharePoint excels and where it does not will result in a diaster. Unless you have the time to understand the core concepts of SharePoint I would warn against it but your client is right. If you do build it in SharePoint you get a great deal more flexibility. One right off the bat is the ability to mix authentication modes. I designed a solution that mixed custom forms authentication with an LDAP backend with Windows Authentication. Anyone could visit the same pages but your authenticated account could come from two different locations.
This is a matter of what kind of concerns you want to have in the application:
Building it to look and function your way, go with sharepoint.
Building it to have infrastructure for authentication, permissions, http/web security, scalability, backup, database maintenance PLUS getting it to look and function your way (but now way more under your control), go with a more pure .NET approach.
I would pick the one I am best at, as Kevin said above.
Edit
More about Kevins post: you can also have your application under sharepoint but with full access to the API, in my projects we do it as a normal ASP.NET application, with own masterpages and everything, but we still use the authentication, lists and doc libraries for uploads, roleassignments for permissions etc. Its a very viable hybrid.
You said,
I heard saying that SharePoint
development is very tedious, that the
platform cannot be very easily
customized, etc.
You have been misinformed about SharePoint. All SharePoint pages are ASP.NET pages. You can customize any of them, either directly, or by using Microsoft Office SharePoint Designer, which is free.
Get started at http://msdn.microsoft.com/en-us/sharepoint/default.aspx.
SharePoint is a lot of work and with that amount of users I personally (and being a SharePoint developer) wouldn't bother.
I would go down the ASP.MVC route in all honesty and not because it's new and the latest buzz technology. I would use it because it's hands down faster. This site for example is written in ASP.NET MVC and it handles all these requests per day on I think 3 servers. 2 front end and 1 database. Correct my if I'm wrong with that.
The problem with asking whether Sharepoint is easy to customize is that there's a wide range of levels of customization people are experienced with. And for some reason, most people also seem to think that whatever level they customized Sharepoint to is the extent to which anyone else would also try to customize Sharepoint.
It's hard to talk about degrees of customization in concrete terms. What is "customization" to me is wrangling with the core DAL, fighting with bugs in the CAML to SQL query optimizers, overriding the SPListItem hydration pipeline, etc. To others, "customization" might mean building some web part widgets and deploying them in a WSP. If you find that there is some impedance mismatch between your logical model and Sharepoint's working model, you will have a really hard time reconciling the two.
Welcome to the dark land of politics.
It's worth making sure that your team properly evaluate and understand any compromises that SharePoint will have you make. Asking here is a good start. Things I'd look at include:
What's the whole solution going to include? Often the administration of a site can involve as much or more development work as the front end. While the 3M+ user front end is the glamorous part it may not be the bulk of the work.
Are there reference sites for 20K+ simultaneous user SharePoint sites? Honestly? What kind of hardware did that require? Is that available?
Get a small group of experienced contractors in for a few weeks to properly estimate the work, both on ASP.NET MVC and SharePoint. Make sure they've worked on large sites. (There's plenty of contractors around at the moment!)
Also, anticipate failure. Have a fall-back option:
If the MVC technologists win out, expect heat from senior management, and possibly even a skunk-works we'll-do-it-properly-anyway project that duplicates your efforts.
If you do end up with SharePoint, listen very carefully to users throughout the development process and be prepared to create Web parts, MVC pages or whathaveyou to address problem points.
I've been in a similar situation where it turned out that there was heavy vendor influence at a very senior level. The senior team had bought into SharePoint and required it to be used for all internal systems; the OCTO (Office of the Chief Technologist) had mandated open-source technologies. It was fun to watch the fur fly in the middle.
(Our option in the end was to use a service-based architecture based on REST, which effectively booted the current version of SharePoint out of the system altogether.)
I would build this on SharePoint. It is quite suitable for big sites and many sites have already been built on it: topsharepoint.com
SharePoint (like all complex applications) does require sufficient knowledge that you do not seem to have at the moment which is a big risk in my mind. Don't listen to the nay-sayers though.. lack of knowledge is a common problem for devs dealing with SharePoint but it doesn't mean you can't make it do whatever you want.
Regardless, what other options do you have? I think the days of building completely custom CMS's have passed just as building completely custom Intranets are not cost effective anymore. There are many competitors to what they want to do with SharePoint (Umbraco, Sitecore, Sitefinity, etc) and most of them seem better than 100% custom.
So the answer might be neither ASP.NET or Sharepoint..
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