Website development for 3 million users: SharePoint OR pure ASP.NET?

Question

For an investment bank, we need to develop a pretty strong web application. . The bank’s IT center would like us to build it on top of the SharePoint platform, but we would prefer to make a clean ASP.NET .

A web application should have the following characteristics.

1) This will be a website for bank customers, which will allow them to view their stock portfolios, receive various reports with graphs and charts, etc.

2) . The web application will also allow customers to send orders to the bank to purchase shares and perform other financial transactions.

3) The number of users will be approximately 3,000,000 (total) and 20,000 at any time.

We have never done any SharePoint programs, 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 support a document library, etc.

However, the bank informed us that SharePoint has many other features that will help us make the project more efficient - for example, it seems that SharePoint has several scalability and high availability technologies .

I heard that the development of SharePoint is very tedious, that the platform cannot be easily configured, etc.

Question : Is it better to create our web application on pure ASP.NET and solve scalability and other problems or build it on SharePoint - taking into account that the web application we need to create is non-standard and complex?

Thank you, Michael.

UPDATE

In the answers, someone suggested using ASP.NET MVC. My other question is: should I use the "classic" ASP.NET or ASP.NET MVC for such a project (if we do not take into account the SharePoint parameter)?

Answer 1

Do you need document management? Do you need version control? Do you need to create "sites"? Do you need audience filtering? You need ECM (fancy word for CMS). Do you need material for collaboration on your site? If your answer is missing, SharePoint is not for you.

You said, “We never did any SharePoint programs,” and for this reason, I think you should not use SharePoint. You also say that your application will be “non-standard” and complex, another reason not to use SharePoint.

It sounds like you know ASP.NET, so I would advise you to stick with ASP.NET or ASP.NET MVC.

Hope this helps

Answer 2

The answer is simple, you have to go with what you know. If you prefer to do this in ASP.NET, then you should go with that. An attempt to master a new technology of this project size will almost certainly cause serious problems in its development. Perhaps you can use the sharepoint scale for this number of users, but you do not know how to do it. This is the real key.

They are true that SharePoint has many features out of the box, but that does not mean that it will make you more efficient because you do not know all the APIs, etc. for access.

Actually, if you want to learn how to cheat. If they force you to use it, you can run ASP.NET applications in SharePoint (good). You can say that SharePoint essentially ignores the path to the site and uses the usual ASP.NET as a web application, like any other site. Actually, this is not using SharePoint, but it can unsettle you in "You need to use SharePoint to make them a happy script."

Mayo suggested contacting MS. I have a feeling that they already have a relationship with the bank, and they gave some idea about the project. I would say: http://www.mindsharp.com/ and see if they can help you. I’m a training company, but I’m sure that the owners will be ready to help in the consultation, and I did not find anyone who has more knowledge in SharePoint than Todd Blaker.

Answer 3

I will not delve into the merits of sharepoint, but suffice it to say that I developed at sharepoint, as it was known as the "digital panel" - it was just introduced today javascript page for Outlook. Regarding its .NET incarnations, it took me about 3 years to become what some might call an “expert” in SharePoint 2007 / MOSS.

First of all, let me give you some warnings regarding the policy of this kind of work. As a contractor, ALL of my work over the past 6 years - covering shaerpoint 2003 and 2007 - without failures, went around me on the spot with a client who required a sharepoint, and a development store with worthy ASP.NET developers who have become hopelessly lost and, rather In total, they blew up 95% of the budget for the last 5% of the project, because they started writing custom platform extensions without a full understanding of the product.

If customers and the stores that serve them have spent more time understanding the product and studying it to see how they can slightly modify or optimize their business processes and requirements according to sharepoint, rather than being rigid in their specifications (which ALWAYS written with zero experience on the platform), and deciding to do custom development, then more general projects will be delivered on time and to the budget. Unfortunately, this is not so.

So, number one: SharePoint 2007 is a great product, but please, for the love of jeebus, find top developers who really understand the product before embarking on this journey. If you do not, you will all fall on fire.

-Oisin

Answer 4

Which CRAP load used in sharepoint is not cut for what the OP wants to use it for. In particular, the comment "Do not be fooled by SharePoint" from ChaosPandion. Maybe he thought it was difficult and gave up ...

Of course, it takes some getting used to developing SharePoint, but it is capable of what op wants most definitely. SharePoint is created using ASP.NET, so everything you do in ASP.NET can be used / ported to SharePoint. This is not a separate product, but the PLAYFORM platform . It will scale to serve many users, using several WFE (Web Front Ends) and SQL Cluster as a backend.

The question here is: is sharepoint the most suitable platform for creating this site? Then I would have to answer, perhaps not so, since the desired functionality is almost all user-generated designs. If you plan to also manage web content, then yes, SharePoint is definitely worth a look. In addition, SharePoint removes all (or at least most: - D) authorization and authentication suspicions. This Ministry of Defense is certified . And if the security offered from the box is not enough, just write an authentication provider (given that SharePoint uses the ASP.NET provider model ).

To answer your questions:

The bank told us that SharePoint has many other features that will help us make the project more efficient - for example, it looks like SharePoint has built-in scalability and high availability technologies.

SharePoint is based on a farm to which you can add machines, each of which performs a different task, which means application server, index server, WFE, document conversion services. WFE may be behind a load balancer to distribute requests. I also want to mention once again the management of web content.

I heard that the development of SharePoint is very tedious, that the platform cannot be easily configured, etc.

As I said, SharePoint is based on ASP.NET, so it is just as configurable as ASP.NET. You can even create an ASP.NET website, put the entire user interface in the controls, and then use this SharePoint, perhaps even the controls use its own database. As for the fact that it is tiring, actually. It's just VARIOUS, and deployment / testing is not like regular deployment / testing. SharePoint uses so-called decision files (.wsp files) to package functionality and deploy it to the server. This IMHO allows you to deploy functionality in a very modular way. In addition, there are many interesting open source projects that greatly simplify the development of sharepoint, as well as provide cool extensions for the “pimps” of your site and make it more fun and easy to use for end users.

Nuff said ....

Answer 5

The development of SharePoint can be tedious, but it can hardly be said that the platform cannot be easily configured. I recently started developing with him full time and so far, I am impressed with the flexibility and suitability for my application, but my needs are very different from what you described.

I understand that 2007 is a big improvement over 2003, so maybe your information is out of date. I heard that 2010 will again be a significant improvement.

It is your task to provide the functionality that the client wishes. If they want a SharePoint solution, if there is no specific reason why SharePoint is really a weaker model, then you should be able to deliver. In case SharePoint is not suitable, you should be able to explain why to meet the bank. I’m not sure that “we don’t know SharePoint” is an acceptable answer in this situation: the bank’s addiction should at that moment find someone who knows both technologies well in order to deliver the product to SharePoint or to better explain why SharePoint really isn’t what they want.

Answer 6

UPDATE: After that, I will add that I do not believe that SharePoint is for you. As I mentioned below, SharePoint is designed for collaboration. If users who come to the site need an isolated experience, then SharePoint has more overhead than you need.

SharePoint is built on top of ASP.NET, so you have everything you want to do with ASP.NET, in addition to what SharePoint provides. Anyone who says this is difficult is trying to do it. You can deploy stand-alone user 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 simply add your own web pages that you can add to any page you choose with 100% of your own code.

Here is just one example.

Create an application page in Windows SharePoint Services 3.0

What SharePoint offers is a completely different paradigm in collaboration tools. If you want to use it (if not the cost of returning is somewhat limited), you can create surprisingly complex and integrated solutions that are built around a set of data from the entire enterprise.

Speaking, do not go into it frivolously. If the deployment is incorrect or with a half understanding of where SharePoint excels and where it does not lead to dialogue. If you don’t have time to understand the basic concepts of SharePoint, I would caution about this, but your client is right. If you create it in SharePoint, you will get much more flexibility. One of them is the ability to combine authentication modes. I developed a solution that combines custom forms authentication with LDAP backend with Windows authentication. Anyone can visit the same pages, but your authenticated account can come from two different places.

Answer 7

This is a question about what problems you want to have in the application:

• Build it to look and work your own way, go with sharepoint.
• Creation of infrastructure for authentication, permissions, protection of http / websites, scalability, backup, database maintenance. PLUS makes it look and work its own way (but now it's a lot more under your control), go with cleaner .NET. an approach.

I would choose the one on which I am best, as Kevin said above.

Edit
Read more about publishing Kevins: you can also use your application in sharepoint, but with full access to the API, in my projects we do it like a normal ASP.NET application with its own master pages and everything else, but we still use authentication. lists and doc libraries to load, role assignment for permissions, etc. Its a very viable hybrid.

Answer 8

You said,

I heard that SharePoint development is very tedious, the platform cannot be very easily customizable, etc.

You have been misinformed about SharePoint. All SharePoint pages are ASP.NET pages. You can configure any of them either directly or using the free Microsoft Office SharePoint Designer.

Start with http://msdn.microsoft.com/en-us/sharepoint/default.aspx .

Answer 9

SharePoint is a lot of work, and I won’t be bothered with this number of users whom I personally (and am a SharePoint developer).

I would go down the ASP.MVC route honestly and not because it is a new and latest buzz technology. I would use it because it rolls faster. This site, for example, is written in ASP.NET MVC and processes all these requests per day, I think, 3 servers. 2 and 1 database. Correct me if I am wrong.

Answer 10

The problem with the question of how easy it is to set up Sharepoint is that there is a wide range of customization levels that people are faced with. And for some reason, most people also seem to think that regardless of the level at which they set up Sharepoint, there is a degree to which someone else would try to set up Sharepoint.

It is difficult to talk about the degrees of customization in specific terms. What is “tuning” for me is the fight against the DAL core, the fight against errors in the CAML query optimizers for SQL, the redefinition of the hydration pipeline SPListItem, etc. For others, “customization” may mean creating some web part widgets and deploying them to WSP. If you find that there is some impedance mismatch between your logical model and the Sharepoint working model, it will be very difficult for you to reconcile the two.

Answer 11

Welcome to the dark country of politics.

It is worth making sure that your team correctly evaluates and understands any trade-offs that SharePoint will have to make. Asking here is a good start. Things I look at include:

• What does the whole solution include? Often site administration can include as much or more development work as the front end. While the front of the 3M + user is the glamorous part, this cannot be the main part of the job.

• Are there link sites for concurrent custom SharePoint 20K + sites? Fair? What equipment required it? Is it available?

• Get a small group of experienced contractors over the course of a few weeks to properly evaluate both ASP.NET MVC and SharePoint. Make sure they work on large sites. (There are many contractors at the moment!)

Also expect a crash. You have a return option:

• If MVC technologists benefit, expect warmth from top management and perhaps even a skunk-works-we-do-it-correct-anyway project that duplicates your efforts.

• If you end up using SharePoint, listen carefully to users throughout the development process and be prepared to create web parts, MVC pages, or whathaveyou to solve problem points.

I was in a similar situation when it turned out that at the highest level there was a heavy influence of suppliers. The senior team bought from SharePoint and demanded that it be used for all internal systems; OKTO (Office of the Chief Technologist) has approved open source technologies. It was fun to watch, like a fur fly in the middle.

(In the end, our option was to use a REST-based service architecture, which actually completely downloaded the current version of SharePoint from the system.)

Answer 12

I would build it on SharePoint. It is quite suitable for large sites, and many sites have already been built on it: topsharepoint.com

SharePoint (like all complex applications) requires sufficient knowledge, which, in your opinion, does not present a great danger at the moment. Don't listen to nay-sayers, though .. Lack of knowledge is a common problem for developers working with SharePoint, but that doesn't mean you can't do what you want.

No matter what other options you have? I think the days of creating a fully customizable CMS have gone the same way as creating a fully customizable Intranet is not cost effective anymore. There are many competitors for what they want to do with SharePoint (Umbraco, Sitecore, Sitefinity, etc.), and most of them seem more than 100% custom.

Thus, the answer may not be ASP.NET or Sharepoint.