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

【问题标题】：Design pattern for a simple CRUD data driven application简单 CRUD 数据驱动应用程序的设计模式
【发布时间】：2011-03-22 03:41:50
【问题描述】：

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

【问题讨论】：

我们不了解您的需求、用例、可扩展性预测等，因此任何答案都纯属猜测。

标签： asp.net design-patterns architecture

【解决方案1】：

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

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

如果它是“商业用户”将使用的工具，那么他们很可能会期望随着时间的推移而发生变化：取决于应用程序的用途，一个简单的直通式 CRUD 应用程序可能只会在短时间内减少芥末。

所以我想这就是您对最佳实践的令人钦佩的渴望所在。你熟悉 OO 设计吗？良好 OO 设计背后的许多原则也适用于架构级别（SOLID、Common Reuse、Common Closure、Loose Coupling、Stable Dependancies 和 Stable Abstraction 原则）。

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

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

完成：

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

【讨论】：

我只是要求为典型的数据驱动应用程序提供标准设计模式，该应用程序将来可能会增长，也可能不会增长。到目前为止，我不知道他们想添加任何逻辑。但是业务总是在变化，所以我想保持这个选项开放，而不是采用快速而肮脏的方法。无论如何，谢谢你的回答。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：

虽然没用过，但我知道这个，但是看了这个推荐后，我会尝试一下。谢谢。