[Office 365 Development Series] development model analysis

Preface

This article is completely original, reprint please explain the source, hope for everyone useful.

Before we formally develop Office 365 apps, let's look at the development model for Office 365 and choose the most appropriate development model for different scenarios.

Read Catalogue

1. Office 365 addin case
2. Office 365 provider Case
3. Features of the Office 365 development model
4. Office 365 Development Mode Scenario analysis

Body

The development model for Office 365 is divided into two main categories:

• Office 365 AddIn app development
• Office 365 provider app development

Office 365 addin CaseOffice 365 AddIn Development refers to the plug-ins developed in the Office 365 app component to enhance or customize the Office 365 components, as shown in the Bing Map that we use in Excel:Bing map renders a map report in Excel by capturing city data from Excel tables, making it easy for users to create intuitive map reports quickly and easily. In a simple look, the discovery does make the user a lot easier to use, but it's not necessarily easy to develop the application, at least you have to have a map. Looking at a plugin for Outlook, Findtime:findtime is designed to resolve the meeting time for each attendee during the initiation of the meeting, and to effectively coordinate the sessions of each participant. How, have not felt the addin brings the benefit. Well, it depends on whether there are good applications that can be integrated into components, such as party invitations, surveys, ... Office 365 provider CaseThe development model described above is a plug-in for Office 365, which means that the app's portal is not available for use alone in Office 365 components. Next we look at another development mode (provider mode), this way of case is not very easy to find (mainly related to copyright issues, worry about infringement), so I do the small product to everyone to see it intuitively: first, compared with AddIn, provider mode can be accessed independently, The portal is in the app itself, not the Office 365 components, as shown, we can better organize the features of Office 365, and Mail, Lync, SharePoint online can be used as background services for apps. This approach can be positioned as a complete set of solutions, not just an application. features of the Office 365 development model

After reading the above cases, we can analyze the characteristics of the two development models, and also want to have a good application case of friends, can be shared in the comments, let us learn more about Office 365 applications.

AddIn mode, app portal in Office 365 components, users need to access Office 365 components through the client, such as Excel, Outlook, SharePoint online, and so on, to manipulate the app in the component.

AddIn Mode Advantages:

1. The development model is more straightforward than the provider model, focusing on specific feature points and better integration with Office 365 components.
2. Apps don't need to implement future user authentication, user authorization, and related interface content, while leveraging the many development APIs provided by Office 365 and even using standard page components from Office 365.
3. User deployment is simple and is directly loaded via the App store without having to sign in to other apps.

AddIn Mode Disadvantages:

1. Because AddIn is based on Office 365 component development, the portal is now set within Office 365, resulting in poor flexibility and difficulty with independent access.
2. The addin mode needs to be compatible with the way Office 365 itself is displayed, with poor user experience flexibility.
3. AddIn mode, the ability to guide the user is poor, unable to provide a complete solution.
4. AddIn mode is limited by the Office 365 component itself, resulting in poor extensibility.
5. AddIn mode relies on the OOB capabilities of Office 365, which is costly to upgrade in the future.

In provider mode, the application's portal is in the app itself, and the user accesses the application-provided services to use Office 365 app components, while the app service can integrate other SaaS-based services.

Provider Mode Advantages:

1. High flexibility, can be positioned as Office 365 product platform, can better provide users with overall solutions.
2. The user embodies the good, because in this mode, we can use the newest front-end technology, brings the user to the higher experience feeling.
3. Integration is good, because the current user information requirements are high, Office 365 can not meet all user needs, so we could integrate more high-quality applications in this mode, and integration with Office 365 to achieve a unified solution.
4. High user viscosity and high product iteration efficiency will result in higher user viscosity.

Provider Mode Disadvantages:

1. Provider mode, we will use the application as a standalone platform, resulting in the number of things we need to do, such as user authentication, user interface, system management, etc.
2. The provider-mode integration of Office 365 is more technically demanding and requires the development team to have a deeper understanding of each component of Office 365.
3. The application of provider mode requires more resource support.
4. The provider mode needs to guide the user through the application platform access, needs the good market promotion.

Office 365 Development Mode Scenario Analysis

Finally, so many words in front of the finished. In the final analysis, although the pattern is a fixed number of classes, but in actual use, we usually mix, we will discuss several scenarios:

1. Existing products, want to integrate products into Office 365, such as Conference room reservation system, content management system, CRM system.

Existing products we can assume that the product already has a complete architecture, and only use the product application in Office 365. At this point, we should use the AddIn model for development, integrating existing app services into Office 365 components, allowing users to use product services in mail, Lync, and OneDrive to supplement the cloud attributes that are missing from the product. This approach can bring a cloud experience to a product that already has users, and it can also bring new app functionality to existing Office 365 users.

2. Enterprise-based solutions, users want to migrate to Office 365

Based on enterprise solutions, companies typically want to migrate existing private cloud solutions to the Office 365 cloud, as the portals, office platforms, HR platforms, and other business platforms needed to integrate into the application, we typically use the AddIn model to enable multiple application integrations for users A unified Office Portal can be built into the SharePoint Online site.

3. You want to develop a cloud-based Office system for Office 365, with the desire to add SaaS-based service applications such as eventnote and other applications to the platform.

If you're looking to build a daily office platform outside of the Office 365 platform, choose Provider mode, use the Office 365 platform as an important part of your product, take advantage of its capabilities, and join other premium apps.

Concluding remarks

Development mode analysis has been completed, the next we will formally enter the actual combat mode, the Office 365 application development process needs to use the function points of one-by-one analysis and practice, I hope you continue to pay attention.

[Office 365 Development Series] development model analysis