Disclaimer: I do no have extensive SharePoint/.NET experience, mostly read through online Microsoft docs, so asking opinion in this forum.
I am modernizing 2 legacy microsoft apps. One is SharePoint 2013 site used for CMS and other is ASP.NET 2.0 web application having transactional frontend. New combined frontend must be JS based common for all screen sizes. Business wants most cost-effective solution, preferably on-prem. I am bit confused about the approach to unify both. 1) Upgrade path - Put ASP.NET into SharePoint farm and then modernize the UI pages. 2) Rewrite with SharePoint frontend - Build using SharePoint Framework (SPFx) which internally supports modern JS frameworks. 3) Rewrite without SharePoint frontend - Build a common JavaScript UI portal (ReactJS) and access the backend REST APIs (including SharePoint) sitting behind an API Gateway.
For Cost effective solution, don't use spfx / ReactJS. Their development environment settings are costly and expired in sometime by new version sooner.
One can rewrite using jsom in SharePoint online , as SharePoint online provides a very good code editor .
JSOM all operations are below :
https://www.codesharepoint.com/jsom/0/all-methods
Approach 1 (ASP.Net in SP Farm) - I would not consider this 'modernizing' as Microsoft's approach going forward is using front-end javascript based applications, which are extremely powerful with the amount of AD integration/Graph libraries/etc. made available. This feels dated in my eyes and could create issues down the road if the company ever wishes to migrate to SharePoint Online.
Approach 2 (SPFx) - This is where the Microsoft ecosystem is flowing with SharePoint modifications. It's also easy to tie into back-end services or other services using Azure App Registrations. There is a lot of flexibility here, you have the option to use ReactJS as well, among other frameworks. I would recommend this approach
Approach 3 (Custom App) - I have built solutions running off create-react-app and similar frameworks and I still try to leverage SharePoint if it is a significant part of the ecosystem as they have very powerful frameworks for tying into it such as PnPjs. It just makes integration so much easier, and you are working within the context of SharePoint vs a custom application on some other server which must be wary of authentication as well as the potential need of a back-end service for communication to SharePoint.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
I'm new to the .net application. am trying to develop an application for Accounting Purpose. Am totally confused that how can I use the design pattern, MVC is preferred. I have to use this app both in Desktop and as a mobile app. App should be more secure.
So please guide me how to design the project. Can you please suggest any examples?
WebApi + MVC is good option I think but for this, should I create 2 solution for both API and MVC?
should it work smart phone as well as desktop?
Database-PostgreSQL
Application will have two parts:
Part I – Accessible to the client through the web page
Part II – Back-end accessible only to us (Company) where all the processing is carried out. Perform the initial setup once the client is registered – create the account in the accounting software and create the chart of accounts
Review and process documents
Accounting – the entries will be passed in the application and will be exported to the accounting software
First of all you can find many tutorials out there on the web about creating a ASP.NET MVC project with Web API.
This can be achieved in one solution as you will see in tutorials.
Example: Getting started with ASP.NET Web API
For the desktop and mobile support, I would like to refer to use Responsive Design. Using a library like GetBootstrap you can create websites that change their content dynamically for each type of device ( desktop / tablets / smartphones / ... ).
Now-a-days everything is mobile. So if you are developing something both for Web and mobile app, API has to be the first and only choice.
The reason behind is that--- More or less what Web shows, APP should also show that, but the layouts or UI are different(here comes the client-side). Moreover if APP needs some extra API, I do not think, that would be much overhead if certain extra APIs are written for the APP. Essentially One API codebase suffices both the paradigms.
It is always a good idea to seperate Client-side architecture with server-side architecture.
I would suggest to seperate the client and server(API), and that would be in best of interest.
Your .net application may serve as client side with MVC pattern where M can call API services and C as usually manages the business logic and V displays the results.
You can write API services(server/backend) in .net, nodeJS, PHP, GO any technology which can manage talking to servers. There also you can create certain architecture or flow of your requests.
Hope that helps
I have a good amount of knowledge in the ASP.NET Webforms and MVC worlds. Shortly I will be tasked with implementing custom web applications with Sharepoint. I have great flexibility with this project (i.e - I can use custom web apps outside of Sharepoint if that's possible) but like most projects the most limiting factor I have to deal with is time.
Here are some questions that come to mind:
Can I easily integrate a custom MVC project into Sharepoint 2010? What are the pros and cons if I can?
Same as #1 only with Webforms.
If #1 and #2 are not viable solutions, can I easily create custom web applications within the Sharepoint world? What will the learning curve be with my background?
I understand developers can now use Windows 7 to deliver Sharepoint 2010 solutions. It looks like I can use a trial of Microsoft Sharepoint Foundations 2010. If that's correct, are there any development differences or gotchas I need to be aware of before digging into the Foundation version? I don't want to get up to speed on Foundation and then find out that the Server edition (the version that will be deployed) is vastly different.
Thanks!
SharePoint is based on webforms - it is relatively easy to add custom user controls and web parts, though if you want to use SharePoint data in a completely custom web app, especially mvc you will probably need to host it seperately - you can access everything you need through the SharePoint API, but it makes the deployment a lot more complicated.
The workarounds to get webforms mvc running in the SharePoint web app tend to involve stuff that would never get past corporate infrastructure people, but I've been getting good results with precompiled razor views set up based on http://razorengine.codeplex.com/ - my version that produces code which can be included in a SharePoint project is at https://github.com/tqc/RazorEngine
In the 2007 version there were significant architectural differences between WSS and MOSS. With 2010 there aren't as many differences, so you should be ok, but it would still be better to develop on the same version you are deploying to - download a trial of Standard or one of the demo VMs - If you do a lot of .net development, chances are you already have an appropriate dev license.
What are you trying to accomplish? Are you connecting your MVC site to SharePoint or are you building something "MVC" on top of the SharePoint server?
In any case, there is an MVC SharePoint project on Codeplex here http://sharepointmvc.codeplex.com/
Here is an article on the subject http://blogs.msdn.com/tom/archive/2009/03/17/asp-net-mvc-and-sharepoint.aspx
I havent touched it, and it seems a bit abandoned to me, but it might get you along.
Check out it outlines one method of running MVC with SharePoint
Generally, SharePoint will simplify many user-oriented requirements you may have - such as authentication, permissions control and personalised areas (with MySites).
If you go with SharePoint, you almost have to build your product for SharePoint Foundation so that you can keep your customers' total costs low (SharePoint CALs, SQL Server, hardware, etc). You'll want to build friendly user interfaces for managing permission, allowing your users to create their own pages, and other provisioning tasks -- or provide rock-solid documentation on how to do it out of the box with SharePoint. With SharePoint, you should use features and Web Parts to deploy your code either way , whether SaaS or on-premise. That will make it easier to deploy and upgrade.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.