I'm developing an application for an internal customer. One of the requirements is that it be developed in such a way that it could potentially be sold to other organizations. The application is a tracking application for a fund-raising organization that will manage their donations, donors, participants, and events. I already know that I'll need to develop a plugin architecture for authentication (authorization will be handled internally) and to derive demographic data from an external directory.
我正在为一个内部客户开发一个应用程序。其中的一个要求是，以一种可能被卖给其他组织的方式开发它。该应用程序是一个筹款组织的跟踪应用程序，该组织将管理其捐款、捐赠者、参与者和活动。我已经知道我需要开发一个插件架构用于身份验证(授权将在内部处理)，并从外部目录获取人口数据。
The application will be built on ASP.NET/C#/Linq/SQL Server. At this point I'm not really open to supporting alternative databases, but I'm thinking I could do this in the future via different Linq drivers, if necessary.
应用程序将构建在ASP之上。NET/C # / Linq / SQL Server。在这一点上，我对支持替代数据库并不是很开放，但是我认为如果有必要的话，我将来可以通过不同的Linq驱动来实现这一点。
All of the web applications that I've built to date have been custom implementations so I'd like to know if there are other things that I need to address via plugins and/or configuration items. Any input would be helpful.
到目前为止，我构建的所有web应用程序都是自定义实现，所以我想知道是否还有其他东西需要通过插件和/或配置项进行处理。任何输入都是有用的。
Thanks.
谢谢。
4 个解决方案
#1
27
I want to caution you against trying to make the "do everything" framework. This is a common mistake that a lot of developers make when trying to build their first few mass-market software apps.
我要提醒你不要试图让“做任何事”的框架。这是许多开发人员在尝试构建他们的首批面向大众市场的软件应用时经常犯的错误。
You have a customer already, and they are likely bankrolling the initial version of the application. You need to deliver as much of what this customer needs as fast as you can or it fails before you even get to thinking about the mass-market.
您已经有了一个客户，他们可能会为应用程序的初始版本提供资金。你需要尽可能快地交付客户需要的东西，甚至在你开始考虑大众市场之前就已经失败了。
Do yourself a favor and expect that this is the only customer that will EVER use or buy the application. Design your application pretty much the exact same as you would have designed any of your other custom apps in the past.
帮自己一个忙，并期望这是唯一一个会使用或购买应用程序的客户。设计你的应用程序几乎和你过去设计的任何其他定制应用程序完全一样。
All you need to do in order to scale it out to other customers later is to stick to the stock asp.net features and functionality as much as possible, keep it as simple and lean as possible, and cut as many "advanced" features from version 1.x as you can get away with.
为了以后扩展到其他客户，您需要做的就是尽可能地坚持使用asp.net特性和功能，尽可能地保持简单和精简，并从版本1中删除尽可能多的“高级”特性。你能逃过的。
1.x will be your proving ground. Make sure you deliver an application that does what your initial customer needs it to do and that it does it exceedingly well.
1。x将是你的试验场。确保您交付的应用程序能够满足最初客户的需求，并且性能非常好。
If you are successful, and 1.x does actually meet most of your initial customer's requirements then you will know you also have an application that will meet most of the needs of any of your customers. Congratulations, you are already most of the way towards having a viable commercial market application!
如果你成功了，1。x确实满足了最初客户的大部分需求，那么您就会知道，您还有一个应用程序，可以满足任何客户的大部分需求。恭喜你，你已经拥有了一个可行的商业市场应用程序!
Things to watch out for:
注意事项:
-
Do you really need to support multiple database platforms? Sure, you might have "some" customers that might "prefer" MySql to SQL Server. You will be tempted to try and write some magic DAL that can support Oracle, MySQL, VistaDB, SQL Server, etc. just by changing some config options or making the right selection in an installer. But the fact is that this kind of "platform" neutrality adds massive complexity to your design and imposes severe limitations on what features you take advantage of. Things like the provider design pattern may fool you into thinking that this kind of design isn't so hard... but you would be wrong. Be pragmatic and design your application so that it will be acceptable to 90% of your potential market. With data access in particular it is generally safe to say that 90% or more of the market willing to install and run an ASP.NET application are also capable and willing to use SQLExpress or SQL Server. In most cases You will save much more money and time by designing for just SQL server than you will ever make in additional sales from supporting multiple databases.
您真的需要支持多个数据库平台吗?当然，您可能有“一些”客户可能“更喜欢”MySql而不是SQL Server。您可能会尝试编写一些神奇的DAL文件，只需更改一些配置选项或在安装程序中进行正确的选择，就可以支持Oracle、MySQL、VistaDB、SQL Server等。但事实是，这种“平台”中立性给您的设计增加了巨大的复杂性，并对您利用的特性施加了严重的限制。像提供者设计模式这样的事情可能会让你误以为这种设计并不难……但你错了。要务实，设计你的应用程序，使它能被90%的潜在市场所接受。特别是在数据访问方面，通常可以肯定地说，90%或更多的市场愿意安装和运行一个ASP。NET应用程序也可以使用SQLExpress或SQL Server。在大多数情况下，仅为SQL server进行设计可以节省比支持多个数据库所带来的额外销售收入多得多的金钱和时间。
-
Try to avoid making "everything" configurable via online admin tools. For example, you will be tempted to have ALL text in the application configurable by admin tools. That's great, but it is also expensive. It takes longer to develop, requires that you increase the scope of your application to include a whole mess of admin tools that you wouldn't have otherwise needed, and it makes the application more complex and difficult to use for the 90% of your customers that don't mind the default text.
尽量避免通过在线管理工具使“一切”都可配置。例如，您可能想让应用程序中的所有文本由管理工具配置。那很好，但也很贵。需要花费很长的时间来发展,要求您增加您的应用程序的范围包括整个混乱的管理工具,否则你不会有需要,它使应用程序更加复杂和难以使用的90%的客户不介意默认文本。
-
Carefully consider localization. If you don't think you will have a large international market stick to one language. Localization isn't too hard, but it does complicate every aspect of your code a little... and that adds up to a lot in any application of any size at all. My rule of thumb is to target only the language of my initial market. If the app has interest in other markets then I go back and do localization in version 2.x after I recoup some cash from version 1.0 and prove the application has a viable market in the first place. But if you know you will be in more than one language or culture, support localization from the very beginning.
仔细考虑本地化。如果你不认为你会有一个庞大的国际市场，那就坚持一种语言。本地化并不难，但是会使代码的各个方面变得复杂一点……在任何规模的应用中，这加起来都是很多的。我的经验法则是只针对初始市场的语言。如果这个应用程序对其他市场感兴趣，那么我就会在版本2中进行本地化。在我从1.0版本中收回一些钱并证明应用程序首先有一个可行的市场之后。但是，如果您知道您将使用不止一种语言或文化，那么从一开始就支持本地化。
-
For version 1.0, don't worry too much about drop-in modules or fancy service APIs. If you already had a lot of experience in reusable frameworks you would be able to have this stuff in version 1.0, but if you lack experience in this kind of architectures you will just waste too much time on these features in version 1.x and you will likely still get it wrong and have to re-architect in version 2.x anyway.
对于1.0版本，不要太担心插入模块或花哨的服务api。如果您在可重用框架方面有丰富的经验，那么可以在1.0版本中使用这些内容，但是如果您在此类体系结构方面缺乏经验，那么在版本1中您将会在这些特性上浪费太多时间。x和您可能仍然会出错，必须在版本2中重新架构。x。
-
Make sure the application has REALLY good reporting. For the kind of application you are talking about, this will be what decides if the application even has a market at all. You need pretty reports that are not only sortable/filterable on screen, but are also printable. Put your money and time into this out of the gate.
确保应用程序有很好的报告。对于您正在讨论的应用程序，这将决定应用程序是否有市场。您需要漂亮的报告，不仅可以在屏幕上排序/过滤，而且还可以打印。把你的钱和时间都花在这外面。
#2
4
The most important thing is to design it in such a way that it is completely generic i.e. there is no client specific information hard coded or embedded.
最重要的是要设计成完全通用的，即没有硬编码或嵌入的客户特定信息。
Anything client specific must be configurable through meta-data. How you do this is completely up to you, but the main ways are through XML, Database or properties files.
任何特定于客户机的内容都必须通过元数据进行配置。如何做到这一点完全取决于您，但是主要的方法是通过XML、数据库或属性文件。
If you design it this way it could be on sold to any number of clients who will each have their own configuration files or data.
如果您以这种方式设计它，它可以卖给任何数量的客户端，每个客户端都有自己的配置文件或数据。
#3
2
Abarax gave a great answer, I'd emphasise that you should consider Localisation - both for spoken languages (english, french, german, etc) and the Organisation's language e.g. some places may call it a Timesheet, Docket or Work Order, and each one will whine and whine and whine if everything doesn't match up with what they've always called something.
Abarax给答案,我强调,你应该考虑本地化,包括口头语言(英语、法语、德语等)和组织的语言如有些地方可能称之为一个时间表,记事表或工作秩序,每个人会抱怨和发牢骚,抱怨是否一切不匹配他们一直所说的东西。
#4
2
If you're using open source technologies, spend a little bit of time keeping all the license information in one place.
如果您正在使用开放源码技术，请花一点时间将所有许可证信息保存在一个地方。
#1
27
I want to caution you against trying to make the "do everything" framework. This is a common mistake that a lot of developers make when trying to build their first few mass-market software apps.
我要提醒你不要试图让“做任何事”的框架。这是许多开发人员在尝试构建他们的首批面向大众市场的软件应用时经常犯的错误。
You have a customer already, and they are likely bankrolling the initial version of the application. You need to deliver as much of what this customer needs as fast as you can or it fails before you even get to thinking about the mass-market.
您已经有了一个客户，他们可能会为应用程序的初始版本提供资金。你需要尽可能快地交付客户需要的东西，甚至在你开始考虑大众市场之前就已经失败了。
Do yourself a favor and expect that this is the only customer that will EVER use or buy the application. Design your application pretty much the exact same as you would have designed any of your other custom apps in the past.
帮自己一个忙，并期望这是唯一一个会使用或购买应用程序的客户。设计你的应用程序几乎和你过去设计的任何其他定制应用程序完全一样。
All you need to do in order to scale it out to other customers later is to stick to the stock asp.net features and functionality as much as possible, keep it as simple and lean as possible, and cut as many "advanced" features from version 1.x as you can get away with.
为了以后扩展到其他客户，您需要做的就是尽可能地坚持使用asp.net特性和功能，尽可能地保持简单和精简，并从版本1中删除尽可能多的“高级”特性。你能逃过的。
1.x will be your proving ground. Make sure you deliver an application that does what your initial customer needs it to do and that it does it exceedingly well.
1。x将是你的试验场。确保您交付的应用程序能够满足最初客户的需求，并且性能非常好。
If you are successful, and 1.x does actually meet most of your initial customer's requirements then you will know you also have an application that will meet most of the needs of any of your customers. Congratulations, you are already most of the way towards having a viable commercial market application!
如果你成功了，1。x确实满足了最初客户的大部分需求，那么您就会知道，您还有一个应用程序，可以满足任何客户的大部分需求。恭喜你，你已经拥有了一个可行的商业市场应用程序!
Things to watch out for:
注意事项:
-
Do you really need to support multiple database platforms? Sure, you might have "some" customers that might "prefer" MySql to SQL Server. You will be tempted to try and write some magic DAL that can support Oracle, MySQL, VistaDB, SQL Server, etc. just by changing some config options or making the right selection in an installer. But the fact is that this kind of "platform" neutrality adds massive complexity to your design and imposes severe limitations on what features you take advantage of. Things like the provider design pattern may fool you into thinking that this kind of design isn't so hard... but you would be wrong. Be pragmatic and design your application so that it will be acceptable to 90% of your potential market. With data access in particular it is generally safe to say that 90% or more of the market willing to install and run an ASP.NET application are also capable and willing to use SQLExpress or SQL Server. In most cases You will save much more money and time by designing for just SQL server than you will ever make in additional sales from supporting multiple databases.
您真的需要支持多个数据库平台吗?当然，您可能有“一些”客户可能“更喜欢”MySql而不是SQL Server。您可能会尝试编写一些神奇的DAL文件，只需更改一些配置选项或在安装程序中进行正确的选择，就可以支持Oracle、MySQL、VistaDB、SQL Server等。但事实是，这种“平台”中立性给您的设计增加了巨大的复杂性，并对您利用的特性施加了严重的限制。像提供者设计模式这样的事情可能会让你误以为这种设计并不难……但你错了。要务实，设计你的应用程序，使它能被90%的潜在市场所接受。特别是在数据访问方面，通常可以肯定地说，90%或更多的市场愿意安装和运行一个ASP。NET应用程序也可以使用SQLExpress或SQL Server。在大多数情况下，仅为SQL server进行设计可以节省比支持多个数据库所带来的额外销售收入多得多的金钱和时间。
-
Try to avoid making "everything" configurable via online admin tools. For example, you will be tempted to have ALL text in the application configurable by admin tools. That's great, but it is also expensive. It takes longer to develop, requires that you increase the scope of your application to include a whole mess of admin tools that you wouldn't have otherwise needed, and it makes the application more complex and difficult to use for the 90% of your customers that don't mind the default text.
尽量避免通过在线管理工具使“一切”都可配置。例如，您可能想让应用程序中的所有文本由管理工具配置。那很好，但也很贵。需要花费很长的时间来发展,要求您增加您的应用程序的范围包括整个混乱的管理工具,否则你不会有需要,它使应用程序更加复杂和难以使用的90%的客户不介意默认文本。
-
Carefully consider localization. If you don't think you will have a large international market stick to one language. Localization isn't too hard, but it does complicate every aspect of your code a little... and that adds up to a lot in any application of any size at all. My rule of thumb is to target only the language of my initial market. If the app has interest in other markets then I go back and do localization in version 2.x after I recoup some cash from version 1.0 and prove the application has a viable market in the first place. But if you know you will be in more than one language or culture, support localization from the very beginning.
仔细考虑本地化。如果你不认为你会有一个庞大的国际市场，那就坚持一种语言。本地化并不难，但是会使代码的各个方面变得复杂一点……在任何规模的应用中，这加起来都是很多的。我的经验法则是只针对初始市场的语言。如果这个应用程序对其他市场感兴趣，那么我就会在版本2中进行本地化。在我从1.0版本中收回一些钱并证明应用程序首先有一个可行的市场之后。但是，如果您知道您将使用不止一种语言或文化，那么从一开始就支持本地化。
-
For version 1.0, don't worry too much about drop-in modules or fancy service APIs. If you already had a lot of experience in reusable frameworks you would be able to have this stuff in version 1.0, but if you lack experience in this kind of architectures you will just waste too much time on these features in version 1.x and you will likely still get it wrong and have to re-architect in version 2.x anyway.
对于1.0版本，不要太担心插入模块或花哨的服务api。如果您在可重用框架方面有丰富的经验，那么可以在1.0版本中使用这些内容，但是如果您在此类体系结构方面缺乏经验，那么在版本1中您将会在这些特性上浪费太多时间。x和您可能仍然会出错，必须在版本2中重新架构。x。
-
Make sure the application has REALLY good reporting. For the kind of application you are talking about, this will be what decides if the application even has a market at all. You need pretty reports that are not only sortable/filterable on screen, but are also printable. Put your money and time into this out of the gate.
确保应用程序有很好的报告。对于您正在讨论的应用程序，这将决定应用程序是否有市场。您需要漂亮的报告，不仅可以在屏幕上排序/过滤，而且还可以打印。把你的钱和时间都花在这外面。
#2
4
The most important thing is to design it in such a way that it is completely generic i.e. there is no client specific information hard coded or embedded.
最重要的是要设计成完全通用的，即没有硬编码或嵌入的客户特定信息。
Anything client specific must be configurable through meta-data. How you do this is completely up to you, but the main ways are through XML, Database or properties files.
任何特定于客户机的内容都必须通过元数据进行配置。如何做到这一点完全取决于您，但是主要的方法是通过XML、数据库或属性文件。
If you design it this way it could be on sold to any number of clients who will each have their own configuration files or data.
如果您以这种方式设计它，它可以卖给任何数量的客户端，每个客户端都有自己的配置文件或数据。
#3
2
Abarax gave a great answer, I'd emphasise that you should consider Localisation - both for spoken languages (english, french, german, etc) and the Organisation's language e.g. some places may call it a Timesheet, Docket or Work Order, and each one will whine and whine and whine if everything doesn't match up with what they've always called something.
Abarax给答案,我强调,你应该考虑本地化,包括口头语言(英语、法语、德语等)和组织的语言如有些地方可能称之为一个时间表,记事表或工作秩序,每个人会抱怨和发牢骚,抱怨是否一切不匹配他们一直所说的东西。
#4
2
If you're using open source technologies, spend a little bit of time keeping all the license information in one place.
如果您正在使用开放源码技术，请花一点时间将所有许可证信息保存在一个地方。