I'm starting an ecommerce project that has very heavy backend integration requirements. I need an ecommerce package that is easy to customize and can function at the enterprise level. If you are familiar with Media Chase and Aspdotnetstorefront, could you let me know what your experience has been and if you lean towards one or the other (or if you recommend a total different platform). Has to be .net. Thanks!
I represent AspDotNetStorefront and we've built thousands of Web sites with dozens of third-party back-end integrations.
If you let me know what kind of integration you're looking to do, I can put you in touch with someone in our authorized developer network to hear about their experience developing for the platform.
We also have a strong community in our forums: http://forums.aspdotnetstorefront.com
I'm sure they'd be willing to relate their personal experiences with the specific kind of development you're looking to do as well.
Good luck with your project!
If you are in need of a .net based enterprise level ecommerce platform I would recommend Microsoft Commerce Server. It is a highly customizable platform, rich in features, and it has many options for back end integration as it uses web services for communication with the back end. If you choose you could also use BizTalk as middleware, and you could then leverage the built-in adapters for commerce server, as well as the adapters for many other systems (ERP, warehouse, etc).
Related
I am web developer specifically from Microsoft background. I have experience in ASP.NET MVC and other JS frameworks. Now point is, I want to learn Share Point. But honestly, I don't have any idea of it. What problems it solves and how much it is beneficial? I have Visual Studio 2012 and SQL Server 2008 Express - Are these software are sufficient to start building a SharePoint application?
Can someone here please brief me on below points
Usage and benefits of Share Point
Software requirements
SharePoint is a big platform and the benefits are that you get lots of functionality for "free" without the need for traditional developer skills. In short you are getting a platform that offers multiple pluggable authentication, a flexible way for end users to create "tables" of data with user defined schema, a ACL model for that data and a forms model for all that data. On top of all that there is an API model for all of that plus lots and lots of other features.
That's the big benefit of SharePoint...lots of things are built into the platform and the developer story is about extending those things to do more. The challenge of course is that there is lots to learn in the platform and you don't really want to fight against the goals of platform, but that is often hard to grok when you are just starting out.
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.
Hi I met an investor who wants a new product to sells to other companies. We agreed to make it SaaS, but we're arguing over three options:
SaaS product using pure ASP.NET
Saas product using huge SharePoint server
A couple of SharePoint add-ons (web parts)
I can't disclose the product but its is about collaboration and involves many interaction between users. That is the reason why we have SharePoint as an option also because a user might optionally create web pages (single home page) many many times.
Some users don't want SaaS. So, there is possibility of hosting the product locally (to protect their 'sensitive' data).
So my question is: which one would you choose from programming point of view?
(Note:I asked this question in onstartup site, and i was advised to ask here for the technical aspect)
It's hard to give a conclusive answer without knowing more details of the project. However, my general advice is to consider SharePoint only if you plan to use its built-in features and don't need to add a lot of custom ones.
Moreover, I recommend you read these questions:
ASP.NET vs SharePoint - which one is better for web developers?
How good/bad is sharepoint programming?
https://stackoverflow.com/questions/256407/what-are-your-biggest-complaints-about-sharepoint
How is SharePoint perceived in your company?
based on tiny info of project , i would Harmonize with marek , as it deals with Collaboration
share point would be the best choice.
There are two things called "Sharepoint". There's Sharepoint Services, and Microsoft Office Sharepoint Server (MOSS). Sharepoint Services provides a lower level framework that you can build other applications upon rather nicely, and doesn't require any additional licensing. However, MOSS requires very expensive licensing, and will only make sense to build upon if your customers already have MOSS. You don't want to force them to purchase MOSS and implement it just to use your product. MOSS is built on WSS (Windows Sharepoint Services).
If you're selling it as SaaS, then that means you will need to buy those licenses, which will be very expensive.
If what you need to do is "Sharepoint with some additional stuff", then maybe sharepoint makes sense. If not, then go with a ground up approach.
SharePoint can be the main solution for enterprise, if users really need RIA and heavy customization, SilverLight would be one of your solution.
I know this question has been tossed around by many developers and designers. I just got finished with my companies intranet site using joomla 1.5 with a custom bulit template and modifying almost everything in joomla. It got me thinking if I should be using an enterprise CMS instead of an free open source CMS. I almost went with wordpress, but the company wanted joomla for there site. It was a great for me to jump into another CMS and learn, but is there a better CMS out there that meant for intranet or does it really matter at all?
Try OpenAtrium, its free.
http://www.openatrium.com
If you're planning an intranet project using a CMS, then you'll need to clarify a couple of requirements before choosing the right one. I have a blog post with some simple choices for choosing a cms for an intranet, more specifically on collaboration and community features. But other more basic requirements are:
Is there a technology stack that the organization prefers/uses? Does it need to be on-premise or cloud based? This will filter down the candidates
Is the Intranet for just posting read-only notices and information, or are community features (groups, lists, news feeds, etc)
Does the Intranet require SSO so that organization members can seamlessly interact with content based on their identity?
What sort of budget is available for the Intranet? All CMS installs have a cost, even the ones without any subscription cost.
Is document and file management an important requirement?
Are customizations needed for any specific Intranet functionality or connectivity to other systems?
Wordpress will do a simple intranet well, but will start to become more work if you start getting complex requirements around authentications, groups and social functionality. If on the LAMP stack and looking for more complex requirements, look at Drupal or Joomla. On the Windows/.NET side there have been suggestions in this answer already - the choices span from full commercial answers such as Sharepoint to those available open source and commercially licensed like Dnn.
Nowadays everything is called a CMS - tools to maintain websites, advanced portals, wiki's, and so on. The requirements for a "CMS" are drastically different for intranets and public websites, however.
Intranets usually have a high level of interaction, lot's of user generated content, different content types, and so on. More users need to be able to login to the system (basically everyone, not just the content editors) with different levels of authorization and different roles in general. Collaboration in general is much more important than with an average "public" CMS based website.
Furthermore you will usually want different types of plugins. Google analytics and SEO are much less important, you'd be more interested in some active user plugin, recent publications, integration with other internal tools (i.e. project management) and possibly exposing other datasources (databases, telephone directories, filesystems with internal documents), and so on.
In my personal experience, Plone is a good choice. It provides most of the above out of the box or through existing extensions and it has excellent integration possibilities with external systems. Cyn.in also provides a somewhat completer plone based solution.
If Plone's too much for you, you could consider some wiki-like system, such as TWiki or MediaWiki
As others have said, it will depend on your requirements.
If you are looking for something more in the enterprise space, then elcomCMS might be a good fit - it's .NET based though (not sure if that rules it out in your case), but has an API and other dev considerations.
Pretty strong as both a web CMS and an intranet.
http://www.elcomcms.com/Product/elcomCMS-Overview/Intranets
I have user long time drupal, but now I switching to WordPress it's much easier, if you don't want to create a community or something like this.
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