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

Question

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

Answer 1

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

Answer 2

+1 Oded。没有冒犯RKP，但你可能会混淆“简单”与“有效”或“物有所值”。我还认为您可能希望更清楚地知道它是什么样的：示例UI设计与逻辑架构完全不同。无论如何 - 对你的要求很好。

如果这是一个“战术”解决方案：预期寿命不长，或者是一个快速而肮脏的开发工具，那么如何构建它可能不是一个大问题。 （还要注意短期战术应用程序最终可能是长期战略应用程序 - 现在正在开发应用程序，因为该企业将其视为“临时”工具：他们认为它仅用于未来5 - 10年（！））。

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

所以我想这是你看到最佳实践的令人钦佩的愿望所在。 你熟悉OO设计吗？优秀OO设计背后的许多原则也适用于架构层面（SOLID，Common Reuse，Common Closure，Loose Coupling，Stable Dependancies和{{3} }原则）。

  

让我们说添加任何额外的UI /业务   未来的逻辑

所以 - 这是你需要预先考虑如何分离问题并允许增长的地方：架构并不意味着你必须做一个大的前期设计，它只是意味着你需要知道如何随着需求的增长，你会发展应用程序。

完成：

• 仔细查看不同的系统质量属性，找出哪些属性与系统特别相关。优先考虑它们。
• 我从Stable Abstraction（SOLID中的D）中获得了很多里程 - 尽早抽象出数据访问等内容。
• 对我而言，另一个非常关键的“最佳实践”是关注Dependency Inversion（SOL中的S），

Answer 3

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