简单 CRUD 数据驱动应用程序的设计模式

Question

我想知道设计一个简单的 CRUD 应用程序的最佳实践，其中一些屏幕更新各种表（例如用于维护应用程序静态数据的管理页面）。最简单的方法是拖动数据网格/网格视图，将其绑定到数据集，并使用数据适配器进行 CRUD 操作。但如果这个应用程序需要可扩展，让我们在将来添加任何额外的 UI/业务逻辑，那么是否有任何设计模式可以帮助解决这个问题？我应该使用对象数据源控件并将其绑定到业务对象，还是有更好的方法来做到这一点？我应该构建一个完整的分层应用程序还是会针对此要求进行过度设计？任何 UI 设计的例子也会有帮助。谢谢。

Answer 1

如果您正在寻找一种真正快速且简单的方法，您可以考虑使用动态数据 http://www.asp.net/dynamicdata 在 Linq2SQL 或 EF4 后端之上 - 几乎不需要任何代码。

Answer 2

+1 奥德。 RKP 无意冒犯，但您可能会将“简单”与“有效”或“物有所值”混淆。我还认为您可能想更清楚地了解您所追求的到底是什么：示例 UI 设计与逻辑架构是完全不同的问题。无论如何 - 谢谢你的询问。

如果这是一个“战术”解决方案：预计不会有很长的使用寿命，或者是一个快速而肮脏的开发工具，那么如何构建它可能不是一个大问题。 （还要注意，短期战术应用程序最终可能会成为长期战略应用程序 - 现在我们正在开发一款应用程序，但企业将其视为“临时”工具：他们认为它只会在未来 5-10 年中使用(!)).

如果这是“业务用户”将使用的工具，那么他们很可能会期望随着时间的推移而发生变化：根据应用程序的用途，简单的直通 CRUD 应用程序可能只会在短时间内停止使用。

所以我想这就是您想要了解最佳实践的令人钦佩的愿望的来源。 你熟悉OO设计吗？良好的 OO 设计背后的许多原则也适用于架构级别（SOLID、公共重用、公共闭包、松散耦合、稳定依赖和稳定抽象原则）。

可以说添加任何额外的 UI/业务 未来的逻辑

因此 - 这是您需要预先考虑如何分离关注点并允许增长的地方：架构并不意味着您必须进行大型的前期设计，它只是意味着您需要了解如何“将随着需求的增长而扩展应用程序..

完成：

• 仔细查看不同的系统质量属性，并找出哪些与系统特别相关。优先考虑它们。
• 我从依赖倒置（SOLID 中的 D）中获益良多 - 尽早抽象出数据访问等内容。
• 对我来说，另一个真正关键的“最佳实践”是关注SRP（SOLID中的S），

Answer 3

http://www.asp.net/mvc是我的赌注。开始和开始都很容易......您不会失望的。 :) StackOverflow 本身是建立在它之上的。