platform: ASP.NET 4.5, MVC 4, C#
I'm currently designing a website that's available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it's https etc.
What I'd like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don't get their site updated as fast as the public one would, and it's also a headache for me in terms of support.
My questions are
What are some strategies to make "corporate friendly" deployments easy and hassle-free?
Are there ways I could keep the site public with just the database inside the intranet (can't see how... but then I'm no techno-know-all)
If I have no choice but to make it locally hosted - then what's the best way to do it to keep my development/support overheads at a minimum?
I hope the mods don't lock this. I'm asking for specific methods and technical approaches to a very real problem.
Thank you,
For #1, there's a many facets to the question. A couple thoughts that might help you think it out:
Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn't really an "update" story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who's getting paid to keep the system updated and running).
Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
Corporate adoption of newer technologies might be slower than you want: You're using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 - having been out for a few years, it's already somewhat proven and has adoption.
For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It's certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one's a business decision.
For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.
If you're only going to support the last N versions, make that very clear. Avoid supporting code that you're already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you're using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.
Answer to only 1) above.
I would recommend a continuous integration tool. We use TeamCity and deploy mvc3 and mvc4 applications to our public as well as privately hosted sites with a click of a button. Previously, we used cruise control, but now we are more satisfied with TeamCity. Read up on them. Might lead you in the right direction.
You may checkout Visual Studio's Web Deployment Packages. They allow you to prepare a package that could directly be installed on your client's web servers.
Related
As I heard that there are many things need to be considered before Deploying a Meteor App, However, it's still quite vague. Anyone please give me some opinions about this issue. Thanks
This is probably the wrong forum for this type of question, since it's highly opinionated and not really in the Q&A format, but I'll give you some of my personal opinions.
Where am I hosting my app?
This has a lot to do with what your app is (Web-based app, Android-only), how many users you plan to have, if this is a public app or something private, how much you have to spend, and many other factors. Options include:
Host it yourself - Could be on a VPS (Virtual Private Server, like Digital Ocean and others), some cloud offering (AWS or similar), or a bare-metal server you have hosted somewhere (like in your closet).
Pay for dedicated hosting - Several out there that offer many different features, like Galaxy or Modulus, etc.
If you host it yourself, then you have to maintain the hosting solution, I.E you need to support it all on your own. This may mean provisioning/installing the OS, installing and configuring the server apps (MongoDB, Node.js, web servers, etc), and maintaining everything over time. The benefits, however, are potentially cheaper hosting costs (although this could be debated) and custom setups/architectures. If you are creating an app that should remain private (I.E. not a public app) you may want to consider this option so you can host it internal to the company and not make it public-facing. There are some tools out there that can ease the process of setting up the server, for instance MUP/MUPX.
For dedicated Meteor hosting, the benefit is that someone else does the installation, configuration, and maintenance of the core apps, and all you have to do is push the button to move your code in. These options can be more pricey as they are covering the IT costs of supporting the environment, but they usually come with the benefit that a) You don't have to install all that stuff yourself, b) you don't have to be an expert at all the "plumbing", c) You don't have to hire a staff of people to support your infrastructure, d) These hosting services usually know how to optimize things properly to get better performance for your app.
Do I deploy manually or do I use some tool?
This depends highly on the answer to #1, as your hosting decision may come with it's own set of tools used to deploy (ex. Galaxy), or you may need to shop around for the best tool for you. For manual deploys, I'd suggest looking at MUP/MUPX, which can automate the deployment of your app, even configuring the web server, DB server, and setting up everything as Docker images. Or, if you want to have more control, maybe take a look at something like Grunt or Gulp, which are more build-scripting solutions (similar to ANT/Maven/Gradle are for Java).
Do I expect a fast growth, or a slow trickle?
Again, this has a lot to do with where you plan to host. Lots of cloud services make it easy to grow/shrink your cluster of servers based on load, but this takes a LOT of configuration past just installing an OS. VPS and bare-metal solutions will be the hardest to expand. Dedicated hosting will depend on the provider.
You need to serious need to think about how you might handle a fast-growth situation, even if you don't think your app will take off. The internet is riddled with apps that failed because they didn't think they would be as successful as they were. It only takes one mention on something like Reddit, Y Combinator, or Product Hunt for your app to get a sudden and unexpected rush of traffic that takes down the server(s). If you know your growth will be controlled in some way, like if you have a private app with a pre-set number of users, then you might not need to worry about it.
Do I need to monitor my app?
The answer to this is always "Yes", but to what extent? Do you need to provide 24x7 uptime? Would an outage cost you lots of money, make you loose your biggest client, etc? Can the users live without service for a little while if it goes down, or would I loose face and customers? Depending on how serious you need to be, you should consider some sort of monitoring of your infrastructure and app. Again, there are LOTS of options here, and your decision might be swayed quite a bit by the answer to the first question.
I am sure there are other questions, but these are the biggest I could come up with.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
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..
We need to increase our knowledge on deployment of ASP.NET Web sites/Web App. We are getting increasingly bigger and more traffic and need a more professional approach. Not too mention, we are also moving up to multiple database/multiple back end/ multiple front end server deployments and we just don't want to screw it up.
What type of skills should we be looking for and is there a typical title people with these skills use?
Thanks,
Actually, We have most of the talents the two answers mention, what we are looking for is I guess what Dave calls the web server guru. I simply want someone to handle the deployment aspect. The developers we have need to be working on their end of it not trying to figure out dpeloyment best practices. Also, we may end up with multiple projects and teams and I don't think each team having a seperate person rolling their own solutions would be as good as 1 dedicated resource for all the teams.
If you're looking to take an ASP.NET application to the next level, you need the development talent.
At least four years of intensive ASP.NET development experience.
A current certification to go with the experience would be good, but don't take the cert over the experience.
Find someone familiar with the techniques used in your app- if it's a Webforms app, don't go looking for an MVC wizard unless he/she also has the Webforms chops, etc.
It sounds like you may be handling the hosting yourself. If this is the case, you may also need to either hire a webserver guru or look into managed hosting. Don't be snookered into thinking you can get your dev to care and feed the hosting environment, it's too much work for one person.
Sounds like you will need at least three people, as the skills may not typically be what one person can do.
You may need a database administrator, to ensure that your multiple databases stay in sync, or backed up properly and configured correctly.
You will need a sysadmin to set up the multiple webservers and to ensure that all the hardware and infrastructure is configured properly.
And, you will need .NET developer that knows ASP.NET as well as the database layer.
If you were hosted then the first two you don't need as your hosting site would be responsible.
If you went with cloud computing then the same, you don't need the first two.
But, regardless, sounds like you need the third.
For the developer, you need to be careful about what skills you need, for example, C# for 4 yrs, ASP.NET for 2yrs, if you need javascript or css then specify that. If you are using any particular libraries then specify that.
I am in process of evaluating MOSS (SharePoint) and traditional ASP.NET for my client's site. The site will be available to client's partners over the internet. I'm interested in differences between these two approaches from following perspectives:
Development perspective. How does development differs? What are pros and cons of both approaches?
Performance perspective. Which platform shall deliver better performance?
By now, we know that not much features of MOSS can be used out-of-the-box, and the features will be added using web parts.
The big difference that you need to be aware of is the licencing. To use MOSS over the internet will require an Internet licence. The actual cost depends on what deal you have with MS, but it is a significant cost.
We have found that it is more costly to develop for Sharepoint than ASP.net pages. Especially due to requirements for the development environment and deployment problems.
From a performance perspective it depends on how you program it. With ASP.net you have more control and therefore, should be able to get better performance.
Do not use MOSS unless you are leveraging the functionality that MOSS provides.
SharePoint out of the box has a lot of great features you will not be able to duplicate as easily. For instance the Office integration. With SharePoint your client can share documents ( word, excel, etc ) and have them kept under revision control.
You can easily setup individual portals for their clients where they can have discussions, share documents, communicate, etc.
SharePoint is also a content management system. Your client can add/edit/remove content as they wish. With MOSS they get the benefit of publishing workflows as well as being able to roll back their changes/deletes. The publishing workflows could spawn an approval process for the changes. Built in
SharePoint's workflow support is a one of the top benefits. You can create them with SharePoint Designer. SharePoint Designer is free from MS. InfoPath forms + workflows provides some obscene opportunities you will not develop as easily on your own.
SharePoint Designer provides an avenue to develop more advanced solutions than the web interface as well as site branding ( look & feel ).
Best thing is, if you create 1 solution, you can bundle it and deploy it. For instance if you setup 1 client portal, you can bundle it and "copy" it to new client portals.
MOSS is a set of additional functionality that you pay for. It can be expensive. You have to leverage the cost of licensing against the cost for you to duplicate what is already available.
Depending on what your client wants you might not even need Visual Studio. A lot of the work can be done by building solutions with whats already there, which is a lot.
Frankly, I don't understand why people compare SharePoint and ASP.NET as if they were competing products. If you need majority of the features of SharePoint (collaboration, workflow, communities, office integration, document management etc), then it may be worth your while to use SharePoint rather than re-inventing everything.
But if you are developing a classic web application, why bring MOSS into the picture? Unless your clients already have MOSS in place and would rather use it to host their apps. And if your clients are really gung ho about SharePoint, you might want to remind them that SharePoint licensing is very expensive while ASP.NET is free!
Part of the curse and blessing of SharePoint is it's ability to be infinitely customized. Most of the features of SharePoint can either be used as-is, customized with SharePoint Designer or replaced entirely by writing your own C# code. This is a blessing because it means SharePoint is infinitely customizable. It's a curse because customizing it can be a royal pain.
That last comment "Do not use MOSS unless you are leveraging the functionality that MOSS provides" by Shiraz Bhaiji hits it on the money.
And I'll even expand on that. Do not use MOSS unless someone in your organization is going to force everyone in the organization to use the MOSS. Because if people aren't forced to learn how to use it and change their ways, you're wasting time and money by migrating to it. Most places I've seen, people continue to use their file shares, and email (Exchange) to share and collaborate with. They never end up using their Sharepoint. I don't know how common that is, however, if you suspect that'll be the case with your organization you should give this aspect more concern.
One of the biggest parts and focuses of MOSS and WSS is "Collaboration" and ECM (Enterprise Content Management). If your clients/partners can utilize these features sharepoint would be a success.
In addition, since MOSS is part of the office 2007 system, it is fully integrated with all office programs and using Exel Services and Infopath Form Services, your users would be able to enjoy web-based Excel and forms without having to install them.
I would also strongly discourage using MOSS if you have to do any sort of customization. If it does what you need out of the box, then great, but otherwise you'll quickly burn time and resources trying to dance around it.
I can't tell from your question whether or not you're aware that SharePoint is built on ASP.NET and Windows Workflow Foundation.
The big difference in my mind is that the Development model for SharePoint assumes that you are developing against a server. This is not as big a deal as it used to be, since it's practical for each developer to run Windows Server 2008 in a private VM. Still, there's no "Visual Studio Web Development Server" when SharePoint is involved.
See Sharepoint tools support in Visual Studio from Somasegar's Weblog, especially the many comments (72 at last count).
Performance wise, it's a tricky one to answer, as it's very depending upon how your custom solution is developed, what hardware platform you're planning on deploying the solution to, etc. I think most people would agree that, in general, MOSS will be slower than an ASP.NET application written in house, primarily because it's unlikely to be as complex and expansive as MOSS.
That said, it's very easy to deploy MOSS across a network load balanced farm (obviously increasing the licensing costs significantly), and share the load that way, thus getting a pretty significant performance boost over a more traditional ASP.NET app deployed to a standalone server.
As others have said re: development, it's incredibly dependant on what you're actually wanting out of the end solution. As Dr said, it would be a major development effort to reimplement some of the core MOSS features, such as it's Office integration, it's document management, version control and fine grain permissions.
If you feel that you're going to have customise a large chunk of MOSS, then the development effort can be quite involved, especially if you don't have anyone in house familiar with the process. It's a big product, and finding your way around it's innards and API is no small task when first starting out.
I should mention that we've had a lot of clients who have gone into MOSS evaluations thinking that there will be a significant amount of work customising, etc, but not realising that actually, 90% of what they want to achieve can be so with minimum development efforts, it's usually more a lack of understand of all the options available to them within MOSS.
I have written a blog entry which compares the traditional ASP.net and the SharePoint apps. You can see that here:
http://manish-sharepoint.blogspot.com/2008/05/comparing-sharepoint-server-with-aspnet.html
HTH