我正在为内部客户开发应用程序。要求之一是它的开发方式可能会出售给其他组织。该应用程序是一个筹款组织的跟踪应用程序，该组织将管理他们的捐赠、捐赠者、参与者和活动。我已经知道我需要开发一个用于身份验证的插件架构（授权将在内部处理）并从外部目录中获取人口统计数据。
该应用程序将在 ASP.NET/C#/Linq/SQL Server 上构建。在这一点上，我并不是真的愿意支持替代数据库，但我想如果有必要，我可以在未来通过不同的 Linq 驱动程序来做到这一点。
迄今为止，我构建的所有 Web 应用程序都是自定义实现，所以我想知道是否还有其他需要通过插件和/或配置项解决的问题。任何输入都会有所帮助。
谢谢。
我想提醒您不要尝试制作“无所不能”的框架。这是许多开发人员在尝试构建他们最初的几个大众市场软件应用程序时常犯的错误。
您已经有一个客户，他们可能正在为应用程序的初始版本提供资金。您需要尽可能快地满足客户的需求，否则在您开始考虑大众市场之前它就会失败。
帮自己一个忙，并期望这是唯一会使用或购买该应用程序的客户。设计您的应用程序几乎与您过去设计任何其他自定义应用程序的方式完全相同。
为了以后将其扩展到其他客户，您需要做的就是尽可能地坚持现有的 asp.net 特性和功能，使其尽可能简单和精简，并从其中削减尽可能多的“高级”特性版本 1.x，你可以逃脱。
1.x 将是您的试验场。确保您交付的应用程序能够满足您最初客户的需求，并且做得非常好。
如果您成功了，并且 1.x 确实满足了大多数初始客户的要求，那么您就会知道您还有一个应用程序可以满足任何客户的大部分需求。恭喜，您已经朝着拥有可行的商业市场应用的方向迈进了一大步！
需要注意的事项：
你真的需要支持多个数据库平台吗？当然，您可能有“一些”客户可能“更喜欢”MySql 而不是 SQL Server。您会很想尝试编写一些可以支持 Oracle、MySQL、VistaDB、SQL Server 等的神奇 DAL，只需更改一些配置选项或在安装程序中做出正确的选择。但事实是，这种“平台”中立性给您的设计增加了巨大的复杂性，并对您利用的功能施加了严重的限制。提供者设计模式之类的东西可能会让你误以为这种设计并不难……但你错了。务实并设计您的应用程序，使其能够为 90% 的潜在市场所接受。特别是在数据访问方面，通常可以肯定地说，90% 或更多愿意安装和运行 ASP.NET 应用程序的市场也能够并愿意使用 SQLExpress 或 SQL Server。在大多数情况下，与支持多个数据库的额外销售相比，仅针对 SQL 服务器进行设计可以节省更多的金钱和时间。
尽量避免通过在线管理工具使“一切”都可配置。例如，您会很想将应用程序中的所有文本都通过管理工具进行配置。这很棒，但也很昂贵。开发需要更长的时间，需要您扩大应用程序的范围以包含一大堆您本来不需要的管理工具，并且它会使应用程序更加复杂，并且难以为 90% 的客户使用不介意默认文本。
仔细考虑本地化。如果你不认为你会拥有一个庞大的国际市场，那就坚持一种语言。本地化并不太难，但它确实使您的代码的各个方面都稍微复杂化了……这在任何规模的任何应用程序中都会增加很多。我的经验法则是只针对我最初市场的语言。如果该应用程序对其他市场感兴趣，那么在我从 1.0 版中收回一些现金并首先证明该应用程序具有可行的市场后，我会返回并在 2.x 版中进行本地化。但是，如果您知道您将使用一种以上的语言或文化，请从一开始就支持本地化。
对于 1.0 版，不要太担心插入式模块或花哨的服务 API。如果您已经在可重用框架方面有很多经验，那么您可以在 1.0 版本中拥有这些东西，但是如果您缺乏这种架构的经验，您将在 1.x 版本中浪费太多时间在这些功能上，而您可能仍然会出错，并且无论如何都必须在版本 2.x 中重新架构。
确保应用程序具有非常好的报告。对于您正在谈论的那种应用程序，这将决定该应用程序是否有市场。您需要漂亮的报告，这些报告不仅可以在屏幕上排序/过滤，而且还可以打印。把你的金钱和时间投入其中。
最重要的是以完全通用的方式设计它，即没有硬编码或嵌入的客户特定信息。
任何特定于客户端的内容都必须可以通过元数据进行配置。如何执行此操作完全取决于您，但主要方法是通过 XML、数据库或属性文件。
如果您以这种方式设计它，它可以出售给任何数量的客户，每个客户都有自己的配置文件或数据。
Abarax 给出了一个很好的答案，我强调您应该考虑本地化 - 包括口语（英语、法语、德语等）和组织的语言，例如有些地方可能将其称为时间表、案卷或工作单，并且每一个如果一切都与他们一直称之为的东西不符，他们会发牢骚、发牢骚、发牢骚。
如果您使用的是开源技术，请花一点时间将所有许可证信息保存在一个地方。