数据绑定采用3层架构？

Question

数据绑定是否适合3层架构？是在Web表单上删除网格视图并将其绑定到LinkDataSource或SQLDataSource被认为是坏的？我看到它的方式，就是表示层与数据访问层交谈。我曾经听说过“专业开发人员”说从来没有这样做，所以如果不这样做，还有什么选择？

Answer 1

当然，数据绑定对于有效地分发数据是必要的。

工具很棒，可以提高生产率。同样重要的是要了解工具生成的内容，即使是在基本级别，以便能够有效地利用生成的代码。

你描述的反应似乎有点极端。如果向导可以生成一些适用于ya的代码，则使用它。如果您不理解生成的代码，那么这是下一个优先级;了解它在做什么以及为什么。与此同时，你有一个人们可以关注的页面，无论它是如何到达那里的。

在工具方面我有点务实。你做你必须做的事。但是，如果在[插入适当的实习长度]之后你还在使用代码生成并且无法自定义或修复它，那么你（如皇室成员，而不是你，你）是懒惰或愚蠢或两者兼而有之。 ; - ）

OT :(几乎）永远不要说永远，除非你想减轻你试图沟通的影响。

我的2比索。

Answer 2

如果它是一个小项目，你可以这样做，但如果你想要你的应用程序。为了能够灵活地支持Windows / Web，您必须使用图层。

请点击此链接http://www.dotnetspider.com/resources/1566-n-Tier-Architecture-Asp.aspx

您应该在Presentation和Data Access层之间有一个中间层，中间层从表示层中拉出，作为自己的层，它通过执行详细处理来控制应用程序的功能。

业务层的主要任务是业务验证和业务工作流程。

当您将业务逻辑组件构建到SDK中时，您实际上将其与Web应用程序以及它执行的任何输入验证断开连接。因此，您的业务逻辑组件是最后一道防线，以确保只有有效值才能进入您的数据库。

Answer 3

当你做一个小项目或原型时，请使用LINQDataSource或SQLDataSource。但是，这些数据源的缺点足够严重，如果它们合适，您可以认真考虑。如果你做一个多层或多撕裂的架构，他们根本就不适合。但是，即使您的架构不是那么严格，您也应该问自己这个应用程序有多大，以及将来您将对系统进行更改的可能性。想要对数据库进行更改时需要花多少时间？

我见过项目是开发人员使用这些数据源，因为那些是在那些漂亮的ASP.NET视频中使用的构造。但是，当项目从原型扩展到大型生产应用程序时（是的，我已经看到它发生了，原型似乎足够好），缺乏编译时支持（你的查询在标记中定义！）使得它很难做到对系统的任何改变。

当您需要对系统进行更改时，您将看到更改的成本比通过奉承您的体系结构所节省的时间更大的时间。