我正在尝试构建一个内部网，成千上万的员工可以在该网站上创建，编辑和发布文档。
这些文档相当简单（可能是一个富文本字段和一些其他更简单的字段）。
我想将它们视为Umbraco后端文档（而不是在单独的SQL表中说明数据），因此它们可以包含在部分视图中。
还会有其他更复杂的文档，但这些文档将由较少数量的后端用户管理，所以没关系。
我认为将数以千计的员工视为用户并不正确，因为我读过这会导致性能问题。
因此，在放弃之前，我最后的想法 - 由其他人建议 - 是将它们创建为成员，创建一些包含表单的前端页面，然后他们将这些表单提交给新的控制器，可以检查其成员资格并使用API来创建，编辑和/或发布提交的文档，
他们应该只能编辑自己创建的文档，因此控制器需要知道登录成员是谁（并将其与我将作为创建者存储在所有文档上的成员身份ID进行比较）。
很抱歉提出这么多问题，非常感谢任何可以提供帮助的人。
答案 0 :(得分：1)
Ad.1。检查 ContentService 文档（https://our.umbraco.org/documentation/reference/management/services/contentservice），然后使用它来创建从前端到Umbraco文档的新内容节点。您还可以检查 Umbraco Rest API （https://our.umbraco.org/documentation/implementation/Rest-Api/），但它仍然在v1.0.0之前，因此可能会导致一些问题（尤其是安全性问题）。我在这里写了一篇关于使用API的文章：http://24days.in/umbraco/2015/umbraco-rest-api/。
Ad.2。您可以这样做，但它不是推荐的解决方案。 MVC应用程序默认创建为WAP（Web应用程序项目），所有* .cs文件不仅编译来自App_Code目录。如果您有一个典型的WebSite项目，那么从架构角度来看，将业务逻辑与网站/ Umbraco实例分开并将其放在单独的DLL中会更好。顺便说一句。你为什么害怕部署？ ：）
Ad.3。当然！ Umbraco使用ASP.NET Identity，因此可以扩展为使用任何自定义OAuth提供程序。甚至已经为我们创建了几个。检查：https://our.umbraco.org/Documentation/Reference/Security/和https://github.com/umbraco/UmbracoIdentityExtensions。这是为访问Umbraco Backoffice而描述的，但也有允许对成员使用Active Directory登录的包（例如https://our.umbraco.org/projects/developer-tools/active-directory-providers/）。
快乐的编码，我希望我帮助过！