As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to understand the differences in applications developing in Sharepoint and Standalone Silverlight application. My application is going to be a dashboard kind of application which some charts and graphs with metrical data.
Can anyone summarize Pros and Cons of developing this application in Sharepoint
and Pros and Cons of developoing this application in Silverlight
SharePoint will give you control on the data itself. You'll be able to include scenarios involving workflows (e.g. approval) or where access is restricted. For example I worked on a project where the customer had two vendors, and of course he didn't want vendor two to see vendor one 's data on the dashboard.
SharePoint will also give you more rendering options, either html or Silverlight. This will be useful if you need to support a wide range of devices (including mobile).
The cons are the overhead involved with the SharePoint deployment.
As John Saunders said, it is a broad topic and there is no simple answer. One important factor to consider is the size of your project. If you are in a corporate environment involving collaboration, most likely SharePoint will be a good option, either with or without Silverlight.
Presumptions-
You are required to involve SharePoint in some way (intranet? managers use SharePoint?)!
SharePoint
Pros
Direct access to SharePoint data and objects
Easily added to SharePoint sites/pages etc
Cons
Stuck within the SharePoint platform
More involved to get the development environment going (maybe you already have this setup)
It's SharePoint
SilverLight
Pros
Can be viewed in any browser with the SilverLight plugin
Can itself be displayed within SharePoint (e.g. appears to be in SharePoint)
Not tied to SharePoint
Cons
Requires the SilverLight plugin to be installed on each client's machine as well as the correct version etc
May need to access SharePoint web services rather than having direct access to SharePoint (If your dashboard data comes from sharepoint)
A separate server (or the same) to host any WebServices that it might require
Edit
It's possibly worth you mentioning what control sets you have access to as if you have licenses to either SharePoint or SilverLight third party controls this might effect what the result of your Dashboards are
Feel free to add to this...
SharePoint and Silverlight are able to access the Data directly. Think about
ClientObject Model / Server Side Object Model
REST Service
SharePoint WebServices
Building dashboards in SharePoint (by using WebParts) are OOB configurable for the user. The users already know how to use SharePoint because of it's consistent UserInterface.
The advantage of Silverlight will be that you dashboard could be installed on the desktop if you're adding OutOfBrowser support.
I think Silverlight has some disadvantages, but they really depend on your requirements and on your target audience
Reach (on the internet only a few percent have installed Silverlight plugin)
Security (based on SharePoint there is already a security model)
SharePoint is offering a lot of platform features which will cost a lot of money to reinvent them in Silverlight.
Just my cents ;)
Thorsten
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm about to start building my first mobile app and wanted some direction. The app will need to:
run on iPhone, Windows Phone, and Android
access data from a database
be able to determine where it is (e.g., when I cross a state border, when I enter a city, or, generally, when I change locales)
the GUI will be relatively straightforward
After doing a bit of research, I have a few questions:
Should I use a framework (e.g., Rho, Appcelerator, or PhoneGap) or HTML5/CSS3/JS? Or, would I use both of those in combination?
I want to sell the app, so does that preclude building it as a website (i.e., HTML5/CSS3/JS)? In other words, if I build it as a website, doesn't that mean a user won't have to download it and install it like a native mobile app? I like the idea of making it a "native" mobile app vs. a website, although maybe I shouldn't.
Is REST the best way to access my data? My thought is to have a SQL Server database and build a REST service using .NET.
And other tips or guidance would be greatly appreciated.
Thanks,
Jay
If you use a tool such as Appcelerator then you the end product will be native. Appcelerator framework obfuscates the underlying native interfaces for android/iOS. There are a few instances where you'll need to know the differences between the two, for example when to use what Appcelerator class for each device, but in essence, you can write once and deploy to each device. Been using it for a while and is very nice. Appcelerator will give you all the hooks you need to tap into the devices natively.
PhoneGap will just wrap up your app and create a 'web app'. Basically a packaged website. IMO Appcelerator would be the way to go. This is more similar to your second bullet. You'll build the website, you just won't host it on a server. It will be packaged up and deployed to the device. In essence the phone becomes the 'web server' but only in the sense that the device is reading web pages that are local to the device.
As far as data, REST might be the best way to go. the calls would be quick. You may not really need to build your own DB. You might want to look and see if some of the data you are going to use is already out there. Unless you are collecting data. I don't know the details of your app so I'm not sure what help this opinion provides.
Hope this helps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In my organisation we write many custom mobile solutions for many different clients. We have started utilizing Microsoft Dynamics CRM 2011 in some of our test products however almost all of the work we are using it for is done with custom entities and the solutions are utilizing it as a back-end database. From my impressions so far, using CRM in this way is counter-intuitive and slow.
From your experience, would there be any benefit I am not seeing by using CRM instead of a normal SQL Server? I have only seen very basic stuff on the CRM front-end but am not sure how the custom entities become useful in CRM?
I write a lot of code for CRM and you are right, it isn't quick. It's benefits aren't for the developer though, they are for the end user. Through workflow and customisation they can create their own system to their own needs and can use the in-built entities to help manage their businesses.
That said, if you are not putting CRM in front of the customer (or using it internally for its true purpose) and are just using it as a database for your application, then this is not a good approach. You'd be better off talking directly to SQL Server.
Microsoft (and many partners) leverage Dynamics CRM as a platform for rapid and extensible development. There is a term we use: xRM that implies you can build many different applications types faster than traditional custom development.
I have used Dynamics CRM in situations simply because of it amazingly granular security capabilities (and built a custom UI for most of the users). Building a row-level security mechanism with the capabilities found in OOB Dynamics CRM 2011 would be a daunting task in itself...I often tell my new CRM developers, "when you are building your CRM, make sure you include: user data imports, row-level security, solution file deployments, simple form customization, custom views, etc."
With CRM 2011, you start with all of that and have a product with well designed extension points (plugins, workflows, web resources, JScript API, OData, SOAP). All without writing, testing, debugging a single line of code. The other thing I tell developers: coding is expensive, so don't write code :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know they both use MVVM. Both are used in web development. But should I consider using both in a web app? Is that redundant? I've seen I can use KnockoutJS with [ASP.NET] MVC. But I don't know if I can use it with Silverlight in that way or any other way for that matter. I'm a bit new to both, so I don't know how to go about it.
Silverlight and HTML/JavaScript/CSS are both client technologies. So you would choose one or the other. Knockout falls into that HTML/JavaScript category.
On the server you can use any web services you want. Microsoft or otherwise. But if you like ASP.NET MVC, you can use the actions it provides ass your web services. Or you can use WCF services for the web services, too. In MVC 4 beta there is even a special controller type made for service calls (the WebAPI).
But the real answer is "it depends". Your selection depends on what you are trying to accomplish, your skills, who will maintain it, etc.
Not everyone uses Windows, besides Silverlight does not work on Android, iOS.
They are used for different purposes. What exactly do you want to do in your project?
BTW, knockout.js is included in ASP.NET MVC 4 projects by default.
If you don't know what is knockout I think you totslly don't need to use it)
Maybe the question is: what to choose between asp,net mvc and silverlight?
It's totally different technologies just using same pattern.
If you need to support large amount of users on different devices including old browseres you'll better to use jquery (knockout) or you planning rich feature app for small group of people (like admin interface) its easier to use silverlight.
And surely the is no problem to use them together
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Our organization is looking to put up a site utilizing DotNetNuke, and according to our consultant (who is less a .Net fan and more of a Joomla fan), there is 'anecotal evidence' that the Community version is crippled in a way that pretty much forces you to get Pro if you wish to have a reliable site.
I have serious doubts as to the validity of this claim, but just in case I would be very interested to hear if this is or is not the case, based on use of the product and it's community and professional versions.
Specifically, if there are bugs/issues/etc in the community version that are resolved only by upgrading to pro.
I apoligize in advance if I posted this on the wrong stack exchange, but figured this was the best bet ;)
I would definitely disagree with that assessment.
The only Pro feature that I can think of that might affect reliability is a different caching provider (which we've had more problems with than the standard caching provider). I believe it's the suggested provider for a web farm scenario, but in most typical scenarios it won't be a big issue.
The community edition is the same community edition that's been used in real sites for years, there's been no crippling to it since the introduction of the Pro version. The Pro version is just a number of custom extensions on top of the community edition, most of which are quite optional for everyday use a website.
The Edition Comparison on DotNetNuke.com shows the following inequalities:
Advanced Content Approval Workflows
Content approvals ensure any of your users impacted by a content change can approve updates before they go live. Workflow approvals can be configured in a top down hierarchy at the site, page, and module level. A business rules engine enables workflows with an unlimited number of states and reviewers
Granular Permissions
Page, module and folder level extended permissions provide granular security rights which allow you to precisely define which content contributors can edit which modules on each page.
Advanced Site Search
The search engine includes rich query syntax with support for Boolean searches, phrase searches, relevance searches, wild cards, fuzzy searches, and groupings. Includes a true web spider that is capable of indexing any site which removes the requirement to implement the ISearchable interface within modules.
Configuration Manager
A host user can manage the various configuration files that control run-time operation. Upload a Configuration Merge script which can be used to automate many of the more repetitive and complex configuration operations.
Content Staging
Content contributors and software engineers make all changes to your web site on a physically separate staging server. You push the staging site to production when all changes have been reviewed, tested and approved.
My Editable Pages
Links to all of the pages and modules in the site which a user has permission to Edit are displayed, allowing efficient page editing
Document Management
A complete document management solution which allows your organization to store, control and view documents online
Module Caching
A database caching provider for module content which stores module content in a centralized database for faster page loading without requiring web server processing.
Page Caching
Allows your site to save an entire page of rendered content to one of three different caching locations: memory, database or disk. Improves page delivery speed for site visitors.
Distributed Caching Provider
More efficient resource usage in large web farms
File Integrity Checking
Checks files in the installation and reports any inconsistencies which may impact website reliability
Health Monitoring
Pings your web site periodically to identify failures and will notify you of any problems. Also ensures the site stays in web server memory for faster visitor accessibility
Security Center
A host-level feature which dynamically loads a list of known security vulnerabilities affecting your version of DotNetNuke and provides you with navigational guidance to acquire the latest upgrade
Comprehensive Product Documentation
Includes more than 2,800 pages divided into User and Superuser Manuals
Online Knowledge Base
Provides guidance for DotNetNuke administrative tasks and answers to common technical questions
Impersonate User
A host-level feature that allows you to impersonate another user who is a member of your web site. Search for a user by name and then click an icon to assume their identity to view the site using the user’s permissions while keeping their password confidential.
Outside of the three caching items, I don't see anything in there that's more than icing on the cake. Also, having used many of those features, they aren't quite as impressive as they all sound, and the DNN community core isn't completely devoid of any similar features. Module caching, in particular, is available in the community edition, there's just another provider. Also, page caching is possible in the community edition, it just doesn't come with any page caching providers built-in.
Quite the opposite.
Disclosure: Scott Willhite, Director of Community Relations for DotNetNuke
There is absolutely NO limiting code in the DotNetNuke Community Edition, and I am quite proud of that fact. We have made a purposeful and, frankly, very challenging business decision to keep our Community Edition the base of all of our software. We engage in enhancement of the base Community Edition to produce Professional and Enterprise editions using the same extension points that are available to all developers. And we constantly add features and capability to the Community Edition which benefit all users of the platform. Any suggestion to the contrary is unfounded and misleading.
Some companies choose to limit their free editions (by number of users, number of content items, number of pages, etc). Some require branding that can't be removed in free editions. Others specifically use their free editions as "hooks", knowing that a customer of any size will be forced to upgrade if they want to continue using the product. None of these approaches is acceptable in a truly open source environment and none of them are in practice with DotNetNuke.
It is fair to say that we have resources working on proprietary extensions to distinguish our Professional and Enterprise edition offerings. But this is the same privilege we enable hundreds of thousands of others to enjoy who develop for or implement proprietary solutions using DotNetNuke. We are also customers of those extension points and so are constantly improving them for everyone's benefit because we don't just use them as marketing points, we base our companies products on them. Every release of DotNetNuke contains both substantial Community Edition as well as commercial edition enhancements.
To specifically answer your question... while there are no constraints within the Community Edition of DotNetNuke, and it is a highly functional application out of the box, it cannot address every need (no product can, all projects have unique requirements). This is why it is constructed with well defined extensions points and why there is such a vibrant open source and commercial ecosystem supporting it. So it is fair to say that the solution, out of the box, may not address all of your needs specifically? But between Professional & Enterprise options, 000's of commercial extensions on Snowcovered, 00's of open source options in the DotNetNuke Forge and myriad developers and integrators in the ecosystem (in addition to your own skills), I am confident that any need can be met in the way that makes the most sense for your or any application.
I too would disagree strongly. I've been working with DNN for years, well since version 3 and there is no great conspiracy to force CE users to upgrade to Pro. I've rolled out 100+ Community Edition sites (seriously, no exaggeration) and the ONLY PE sites I've worked on were usually government or educational institutions where they needed content staging or the benefits of the OpenDocument Library module. To me, it sounds much like you say - your consultant is letting his opinion of .Net vs. PHP flavor his recommendations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
Why not to empower WPF or ASP.NET instead of creating a new product?
ASP.NET is simply a server-side language for websites. While they have added support for things like AJAX ASP.NET Controls, it still can't come close to the level of richness Silverlight is capable of.
And then WPF requires the 200+ MB .NET Framework which can only run on Windows.
Silverlight was created as a lightweight 5 MB plugin that can run on Windows and Mac alike while meeting strict security guidelines for Internet use. From my point of view, Silverlight is a different tool for a different purpose.
WPF is meant for regular desktop applications and cannot be embedded in a webpage (XBAP isn't the same), and ASP.Net has nothing to do with Silverlight. (ASP.Net is a server-side technology; Silverlight is client-side)
To complete with flash and offer an all in one solution to all types of development and take over the world. Not that it will beat flash and its lineup of tools any time soon.
Because no matter how you empower ASP.NET or WPF you won't get the richness of Silverlight, Flash, ... in a web browser. Javascript's kind of limited.
ASP.NET runs on the server, what was needed is something to run on the client.
WPF is empowered enough already, what was needed is something which can run on the client in a secure manner and that can't be used easily to do malicous things. In other words far from "empowering" WPF, some form of WPF needed to be seriously curtailed.
In addition it can't be assumed that a full .NET framework is present on the client, Silverlight is designed to contain just enough of the needed framework to make things happen with minimal requirements on the client.
A better question might be - why are WPF and Silverlight 2 separate things?
My best guess is that the decision was made to separate them "because we always have separate technologies for developing web vs. developing desktop applications" - but things are not nearly so cleanly split anymore and would make sense to see the 2 merge together.
Probably starting from scratch you wouldn't have both Silverlight and WPF.
I suspect that deep in the MSFT psyche they still don't 'get' the web - WPF was a way of modernising drawing on the desktop, adapting it to web was obviously an afterthought.