Can one create a good e-Commerce application using a tool like DNN merged with some ready made shopping cart? I did not use DNN before, but I think, it will be tough thing to do, I think I will face troubles with performance and maintainability.
Further I think it is almost impossible to convert asp.net web application to DNN, this will wast more time even if I throughaway the UI layer.
Probably it is good to create a small e-commerce application using DNN, that kind of applications that costs 3000 USD, created for once, and not likely to extended.
Talk to me about this.
Thanks
Can one create a good e-Commerce application using a tool like DNN merged with some ready made shopping cart? Yes... But you'll be better served by just using some of the off the shelf cart modules for DNN.
Further I think it is almost impossible to convert asp.net web application to DNN, this will wast more time even if I throughaway the UI layer. This entirely depends on your skill level in writing DNN modules and the needs of the application. No way to even answer other than to say: Why bother? If the application is done and ready to go, there's probably not much of a reason to rebuild it within DNN.
Probably it is good to create a small e-commerce application using DNN, that kind of applications that costs 3000 USD, created for once, and not likely to extended. There are numerous free and open source eCommerce modules for DNN. There are also several good paid for eCommerce modules. Why bother creating your own? Especially if you don't have much experience in writing modules for DNN...
I'm not clear on what your goal is. Plenty of people operate e-commerce sites using DNN. If by large you mean you are looking to take on Amazon then DNN is not for you.
In my opinion DNN's strength is around content management, if you need significant content management and commerce functionality then DNN is likely a good choice. If your primary concern is commerce functionality with little or no other content management needs, then I would look to something more focused on commerce.
It is very possible to convert existing apps to DNN. You will need some understanding of how module development and skinning in DNN works, and then you will find that much of the existing code can likely be copy paste into a module. Once you understand how/when skins and modules are run you will find you can drop in pretty much any ASP.Net code and expect it to work. Of course to take advantage of DNN core features (membership and permissions are common items) you will need to use the DNN APIs. Also it is possible to run DNN side by side with an existing application under the same website.
To me it makes sense to build on DNN if your application will receive significant benefit from off the shelf core and extension module functionality. If you can't remove significant features from your development schedule by using DNN, then you probably shouldn't use DNN.
I haven't found the currently available DNN E-Commerce modules to be good enough to run a site that is really focused on E-Commerce. You should make sure NBStore (a free an Open Source Module) won't meet your E-Commerce as it is very well built but isn't particularly feature rich. Catalook, while feature rich, is terribly written, and I highly recommend avoiding it. Most the other available modules don't have all the needed features for a serious online store.
We've been using AbleCommerce when E-Commerce is the primary focus. AbleCommerce is feature rich, very well built, and relatively easy to customize and extend. We have done basic integration between AbleCommerce and DNN where we used DNN for the main site and AbleCommerce for the E-Commerce piece. AbleCommerce just ran as a Virtual Directory within the DNN site. We did not integrate login/user functionality which was fine for the site. If you truly need the capabilities of DNN, this may be a good way to go.
Can we use Drupal as a framework for larger application? Is it suitable for developing big application in its framework, or is there any limitation of it?
I want to use Drupal as a framework in my application. Is it worth?
If you are looking for a development-framework, Drupal is probably not the right choice. If you are looking for a suite to build websites, Drupal is probably the right tool.
People often tell that Drupal is a CMF, where the F stands for Framework, but in reality, Drupal is simply a flexible CMS.
On a high level, web application framework are split into two categories: the MVC and the CMS. Model View Controller being what most people call a framework. CMS being simply a flexible CMS with application-development abilities.
In practice, what Drupal lacks is:
Proper architecture. Most things in Drupal, evolved organically; which causes inconsistency, unexpected behaviour and unexpected barriers. Not saying that Drupal is not build up properly: just saying it has not been architectured: designed as a whole.
Principle of least surprise. Many frameworks allow skilled developers to create sites in a few hours. With Drupal you must gain a lot of experience and best-practices before you can be confident to roll out websites on planning.
MVC. Drupal has a distinct database-layer and a theme(view) layer, but they are unconventional, and often misused. And certainly not after a structural pattern.
unopinionated behaviour: a framework can force certain methodologies, libraries or even encourage certain behaviour, but it should not have hardcoded/none-overridable defaults that dicate your end-product. Or, in English: Drupals core has many defaults that dictate how you are going to set up, layout and structure your website, regardless of your (clients') needs or wishes. Modules or addons come even momre often with behaviour and often looks built-in and/or hardcoded.
DRY, don't repeat yourself: Drupal heavily depends on repeating oneself. Its entire theme-system depends on copying pieces of code into custom files and changing tidbits. Its form-override system requires copying large parts of the default form into custom modules and changing the parts that one wants modified.
Many of these lackings are the main cause for delay and budget-slips, as seen in my +10years Drupal-experience. Where the unopinionated behaviour part has proven the most nasty one to most of the projects I was involved in. Apparent simple features or ideas prove to take up large parts of the entire budget; Tiny details eating away development-weeks; that last 20% taking not just 80% of the effort, but sometimes 300%.
Besides that, Drupal does not follow OO patterns, which (according to the general consensus) is a bad thing. There is no inheritance, not DRY-practice, no object-relation-mapper*) and no unittesting-practice.**).
This might all sound negative, but in reality, people manage to build nice Drupalsites despite all these "downsides". That is because they adhere to the defaults by Drupal mostly (standard where possible, addons where changes wanted, custom development when no other option is left).
*) In fact there is; in Drupal 7, PDO was introduced, but is not (yet?) used as ORM much/at all.
**) In fact: all of core and many contributions have tests, but these are integration tests and a rare unit-test. Integration-tests (DrupalWebTest) install a clean Drupal-codebase+database for each single test. Your average core-testsuite taking over 8 hours to run is not an exception. TDD is simply not (yet) possible.
EDIT Reading into your examples: Drupal is particularly bad in the area of "form wizards", though it has seen improvement in Drupal 7. Another notable lack, in Drupal, is a proper, programmable workflowing system. There are several modules that enhance or replace the simple workflow-system in core, but they are not easy, nor efficient (development-effort-wise) to program against. It sounds like the main features you want, are amoungst the most underdeveloped areas in Drupal
This really depends on the needs of your application. Drupal, while flexible and extensible, is first a CMS and comes loaded with features which may or may not be desired for a web application. But if out-the-box or with additional modules it provide a large matches for the more classic web application features (ie. user management, content management, plugin system, theme layer, etc.), Drupal provides a great framework to avoid re-inventing the wheel (or dependencies on third party/less-mature framework plugins).
Drupal as a steeper learning curve compared to most framework. As a framework, Drupal is build and designed to for the CMS it is. Historically, Drupal puts almost everything in database. The situation is now better with the generalization of exportables and tools like the Features module. Also, unlike most framework Drupal does not use MVC and is mostly not object oriented.
Yes! You can use it as a framework. You'd want to be happy with some of the core APIs like the menu, node and probably the form API. The menu router and access control are quite good.
I've worked on a couple Drupal sites that didn't quite work because the core requirements had little to do with a CMS. Drupal is very flexible but it most suited to content management. You can of course use it as some satellite CMS for some other application. Drupal can also be used for service driven architecture.
If you want to scale up big, you might consider a framework that places more importance on testing and test driven practices. Drupal is a late adopter of these practices and is not mature in this area. It's something that I find frustrating especially on large sites where regression error becomes an issue. Consider something like Ruby on Rails if this is of interest to you.
Good luck!
Note to self: Why would I wish someone luck on a software project? ... interesting.
Drupal 8 change a lot.
- It is OOP
- Using Composer
- Have good cache mechanism in core
- RESTful in core
So now it is easy can be used as framework for any app. At end web all ways have content. E-commerce have content. And so on.
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
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..
Recently I've been asked to develop a small web site/application.
The site should have some code behind it as in any web application, and the client also needs CMS editing capabilities. He is familiar with Joomla, so he wants the same experience.
I have vast experience in writing ASP.NET (C#), and almost no experience in PHP.
From where I see it, I have a few options:
Build an application based on a ASP.NET CMS - I don't know which CMS to choose
Build an application based on a PHP CMS (i.e. Joomla) - The development time will be much longer since I'll have to learn PHP
Build everything in ASP.NET and add basic CMS capabilities myself - There's a chance the client will be less happy with that
So I'd be happy to hear any suggestions regarding the path I should choose.
Thank you,
Don
If you're considering an ASP.NET CMS, I'd recommend you look at Sitefinity. It's built by Telerik (well known control developer) and is pretty robust. I've been developing with it for about 4 years and very happy with the product. They have a community edition which is free, with very minimal limitations in place (you can only have one CMS user login for editing, must have a small 'powered by' logo in your footer, etc.).
The other great thing about Sitefinity is that it is built on top of ASP.NET best practice and principles (master pages, themes, provider model, etc.)
I'd take a look at Grafitti or Umbraco :-)