是否使用 SharePoint（作为应用程序开发的基础）（与 ASP.NET）
我的观点是，在这些条件下，您应该只使用 SharePoint 进行应用程序开发。
1) 应用程序使用文档，并且这些文档需要 SharePoint 非常擅长的某种功能（搜索/索引、与 Outlook 同步等...）如果您想要的只是一个文档存储桶和一个列表，那么 ASP.NET 或 ASP .NET MVC。
2) 应用程序必须使用工作流程或自定义工作流程。 没有工作流程，我会再次转向 ASP.NET 或 ASP.NET MVC。
3) 公司必须愿意为 SharePoint 奉献至少 1 名全职开发人员。 不是开发人员的 1/2 或 1/3。 您需要承诺和专注才能正确进行 SharePoint 开发。 你必须喝酷爱饮料。 如果您不愿意专注于 SharePoint，而只是愿意涉足，那么最终的解决方案会很糟糕（恕我直言）。 如果您可以指定两名开发人员或一个团队（考虑可支持性/维护/专业知识/专业化），那就更好了。
所以你怎么看？
注意：我认为，如果所有 Microsoft 商店选择将 SharePoint 与 Exchange 配对作为其协作架构的一部分，那么他们都应该使用 SharePoint 的开箱即用功能。 我并不反对SharePoint。
更新
在参加 SP 研讨会后，我了解到 SharePoint 工作流仅适用于每个 SharePoint 列表项。 因此，如果您的工作流不使用 SharePoint 列表项，那么您可能应该查看 .NET Workflow Foundation 或自定义的东西。 将此视为我的#2 项目的替代品。
I have a POV that you should only use SharePoint for application development under these conditions.
1) The application uses documents and these documents need some sort of functionality that SharePoint does extremely well (searching/indexing, sync with Outlook, etc...) If all you want is a document bucket and a list then ASP.NET or ASP.NET MVC.
2) The application must use workflows or custom workflows. No workflow then again I would look towards ASP.NET or ASP.NET MVC.
3) The company must be willing to dedicate at least 1 full-time developer to SharePoint. Not 1/2 or a 1/3 of a developer. You need commitment and focus to do SharePoint development correctly. You must drink the Kool-Aid. If you are not willing to specialize in SharePoint, but only willing to dabble, the resulting solutions are terrible (IMHO). Even better if you can dedicate two developers or a team (think supportability / maintenance / expertise / specialization).
So what do you think?
note: I think all Microsoft shops should be using the out-of-the-box features of SharePoint if their company has chosen to pair that with Exchange as part of their collaboration architecture. I'm not anti-SharePoint.
UPDATE
After sitting in a SP workshop I have learned that SharePoint Workflow is only applicable on a per SharePoint List item basis. Therefore, if your workflow doesn't use SharePoint List items, then you should probably look at .NET Workflow foundation or something custom. Consider this a replacement to my #2 item.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我同意。 目前的 Sharepoint（moss 2007/wss 3.0）使定制开发成为一个非常痛苦且缓慢的过程。 我唯一不同意的是工作流程部分。 在我看来，SharePoint 中的工作流程几乎无法使用，应该避免。 如果您打算进行工作流程，请选择 k2:blackpearl 或 MassTransit 以获得开源免费选项。
I would agree. Sharepoint currently (moss 2007/wss 3.0) makes custom dev a very painful and slow process. The only point I would disagree with is the workflow portion. In my opinion the workflow in SharePoint is nearly unusable, and should be avoided. If you are going to do workflows, go for k2:blackpearl or MassTransit for the open source free option.
假设您有一个数据仓库，从公司的许多点收集数据。 希望您有一些维度可以让业务人员指定为“维度所有者”。 这些人与维度中的数据组织有利害关系。 他们负责使层次结构和列表等内容保持最新，但这些集合并未填充来自事务系统的操作数据，它们是业务术语、组和业务描述。 这是他们自然的商业语言。 东部销售团队、小型企业、高风险、平面广告促销 25 等。关键是您的数据仓库是由 99% 的运营/交易内容构建的，但业务安排使其对您的用户来说一切都有意义，并且您需要一个捕捉它的地方。
您当然可以制作一个网络应用程序。 您可以使用 Excel 文件。 任何。 但您也可以使用 SharePoint 列表。 SharePoint 的吸引力在于，当环境已经存在（因此受支持）时，当您的要求不广泛（即不需要引用完整性）时，您没有资源来创建新的 Web 应用程序，业务用户已经熟悉并熟悉 SharePoint，您昨天就需要它，等等。
所以我在这里不是在谈论编写代码和编译要安装在 SharePoint 上的库。 我只是想提供一个合理的“正确的时间和地点”来使用它。
顺便说一句 - 这是一个非常方便的如何在 SharePoint 列表和SSIS。
Let's say you have a data warehouse that collects data from many points in the company. Hopefully you have a few dimensions that have business folks designated as "dimension owners." These are the people that have a stake in the organization of data in the dimension. They are responsible for keeping things like hierarchies and lists up-to-date but these collections aren't populated with operations data that come from transactional systems, they're business terms and groups and descriptions that the business speaks. This is their natural business language. East Sales Team, Small Business, High Risk, Print-Ad Promotion 25, etc. The point is your data warehouse is built from 99% operations/transactional stuff but it's the business arrangements that makes it all sensible for your users and you need a place to capture it.
You certainly can make a web app. You can use an Excel file. Whatever. But you can also use a SharePoint list. Where SharePoint is attractive for this is when the environment already exists (and thus SUPPORTED), when your requirements aren't extensive, i.e., referential integrity not required, you don't have the resources to create a new web app, the business users are already familiar and comfortable with SharePoint, you need it yesterday, etc.
So I'm not talking here about writing code and compiling libraries to be installed on SharePoint. I'm just trying to present a reasonable "right time and place" for it to be used.
BTW - Here's a very handy how-to on pushing and pulling data between SharePoint lists and SSIS.
SharePoint 应该用作业务用户协作（即存储、查找和编辑彼此文档）的基础。 仅使用 SharePoint 进行应用程序开发会造成伤害，并且需要问题中提出的第 3 点。
对于应用程序开发，我更喜欢使用 SharePoint 作为 Web 门户，将用户引导至应用程序或托管其 Web 界面（通过用户控件、Web 部件等）（哦等等，我已经准备好说 SharePoint 是一个 Web 门户了）。
SharePoint should be used as a foundation for business user collaboration (that being storing, finding and editing each other documents). Using SharePoint merely for application developement hurts and requires point 3 made in the question.
For application developement, I prefer to use SharePoint as a web portal that points users to the application or hosts it's web interface (via user controls, webparts and the like)(oh wait, I all ready said SharePoint was a web portal).
即使没有文档，您仍然可以使用 Sharepoint 作为具有自定义 Web 部件（也许其中一些基于站点文档库）的门户平台。 这是一个很好的门户平台，我公司的研究门户是基于共享点的，而且运行得很好。 好处是，通过这些基于 Web 部件的共享点门户，您仍然可以相对轻松地处理权限问题和演示文稿自定义问题（将 Web 部件拖到特定区域等，这是用户经常做的事情）。 此外，WSRP 类型的 Web 部件与 Sharepoint 配合得很好。
你是对的，只有当你有优秀的 Sharepoint 开发人员时，它才会让你的事情变得简单，并且是一个不错的平台，无论是否有文档。
Even without documents, you can still use Sharepoint as a platform for a portal with custom webparts (maybe some of them are based on site document libraries). It is a good portal platform and my companies research portal is sharepoint based, and it works pretty well. The good thing is that with these webparts based sharepoint portal, you can still take care of permissioning issues, and presentation customiztion issues (drag the webpart to a particular zone etc, which users do a lot, btw) relatively easily. Also, WSRP type webparts work pretty well with Sharepoint.
And you are right, only if you have good Sharepoint devs, then it does make things easy for you and is a decent platform, docs or no docs.