问题标签 [data-layers]

我有许多按以下方式定义的数据层：

我添加到地图中，它出现在图层切换器上，一切都很好。但是，我注意到生成的 HTML 包含以下内容：

您会注意到表单输入 ID 和 NAME 都逐字包含图层名称。这对我来说似乎有点奇怪，因为 ID 和 NAME 属性很容易变得无效。更复杂的是，我希望在图层标签上添加一些标记，以便以不同的语言显示/隐藏图层名称。在表单字段中有标记是 a) 垃圾和 b) 导致 IIS 在提交表单时抱怨“可能不安全的请求”（asp.net webforms，包装页面的单个表单，因此如果没有负载就无法真正逃脱它工作！）

我知道如何规避不安全页面请求警告，但如果我这样做，我的管理员会停下来。我想知道是否有人知道在不干扰底层控制标记的情况下巧妙地设置图层标签的方法？

干杯，史蒂夫

我正在为我的应用程序的主要数据层使用 MS Enterprise Library 5.0（数据访问块）。

虽然我了解 OO 的基础知识（是的，我需要不断学习 - 不断学习！），但我正在努力了解在哪里/为什么/如何使用好的设计，即不要不必要地重复代码等，而且仍然试图保持代码简单易读，当然还有调试。

所以首先，我有以下类和默认/示例方法：（ps：db/proc 的返回值是 XML）

所以..到目前为止非常基本。我只是想在这里建立一个模板，说明我应该如何继续说更多“getMemberContacts”方法。即我应该创建一个通用的“get”方法，它是一个虚拟方法，并覆盖参数？我知道这听起来很治愈，确实如此！我猜是学习的一部分。

所以总而言之，我当然试图重用“get”方法，其中 params/proc 名称明显不同，但是实际返回值（在这种情况下为 XML，因此连接返回的 while/append 部分XML 块）需要相同，即返回可以保留为 XML，或者如果提供，可以返回 JSON。

我意识到这是非常基本的东西/概念，但任何指针/想法都将不胜感激！

大卫。

- - 编辑 - -

只是为了展示 SQL 2008 XML 部分，因为我对关于不直接从 SQL 返回 XML 的评论感到好奇——我再次明白，获取原始数据以便以不同方式使用它是一件好事，但在我的情况下，所有我的前端框架使用 XML 或 JSON（顺便说一下，JS 框架是 www.dhtmlx.com，它非常棒）。

所以 SQL 2008 的过程是：

输出拉回为：

..这正是我需要为我的前端格式化的数据的方式。

我可以看到为什么不使用这种方法的原因——例如，如果我使用另一个框架或需要直接数据表中的数据怎么办..我想我可以有一个参数变量以 XML 或直接表格形式输出..或者我什至敢说两个 procs .. 但同样，有兴趣听到任何方式的评论...

再次感谢所有输入 - 真的非常感谢。

我有一个现有的应用程序，其中包含一个数据层（主要 EF4）、一个业务层（自定义代码）和一个 Windows 应用程序 - 现在我想使用 ASP.NET MVC 创建一个 Web 应用程序，但我不确定具体要做什么，尤其是在我的模型中。

当我的数据和业务逻辑已经存在时，与 MVC Music Store v2.0 (http://mvcmusicstore.codeplex.com/) 等参考项目相比，我应该如何构建我的模型和控制器？我所有的实体都存储在我的数据层中，我所有的方法和逻辑都存储在我的业务层中，所以我想我不需要模型（除非我需要特定的网络模型），我想我的控制器只需要调用我的业务层中的方法我会在一个普通的网络表单应用程序中吗？

另一个问题，如果我需要在 1 页上显示 2 个包含来自 2 个不同实体的数据的列表，我想我需要创建具有 2 个属性的 af 模型（每个实体一个）？

现在的最后一个，如果由于某种原因，例如来自我的业务层的 Get 方法返回异常，应该如何在我的控制器/视图中处理？

我正在创建一个应用程序，该应用程序分为数据层（使用存储库模式和 EF 4.0）、业务层（带有附加逻辑的 POCO）和服务层（使用 WCF 向客户端公开）。

当我将记录保存到数据库时，我需要检查一下我是在更新现有记录还是插入新记录。该责任应该在哪里 - 在服务层中，以便明确管理对象的生命周期，或者在数据层中，以便保存记录将隐含地确定要采取的操作。

欢迎所有评论 - 我无法决定自己！

我一直在网上寻求有关如何设计我的 php 类以分离我的业务逻辑和我的数据层的帮助。我已经开始设计一个我认为很酷的类，但后来发现了 PDO 和 ADODB，并有一个很好的表情，意识到我正在重新创建轮子。我现在的问题是我仍然不太了解如何分离我的逻辑和所有 SQL 查询。

我从我的数据库架构中删除了大部分内容并放下这两个表，因为我认为它们很容易理解。假设我有文件，它们在我的服务器上保存在目录中（这些目录可以在其他目录中）。假设我需要一些基本功能，例如从我的一个文件中获取根目录或获取当前目录中的目录列表。

一个设计良好的类会是这样的吗：

我会在哪里使用通过构造函数传递的 ID 在构造函数中获取我的对象的所有数据？我应该在构造函数中传递一个 PDO 对象还是我错过了一些有价值的设计模式？所有的 SQL 都应该在这里硬编码吗？我使用 PDO 得到的一件事是我可以很容易地从 MySQL 切换到 MSSQL，但是两者的 SQL 语法不同，所以不会仍然给我带来问题吗？

我知道这些都是理论上的问题，没有一个好的答案，但我缺乏工作同事来讨论这个问题（当我说他们甚至不知道设计模式是什么时我不是在开玩笑）所以我发现自己转向了网络。如果我的问题太模糊，请随意提出一个好的讨论类型的地方，我可以问这种东西，我将非常感激:)

我需要编写一个实用程序，它能够从以下任何数据库生成数据层：
Mssql
MySQL
Oracle

例如：我有一个 SQL 数据库，其中包含几个表、视图、过程、函数等。通过使用上述实用程序，我将能够生成所有包含实体类及其映射或类似的数据层，因此，在此基础上，我将能够编写我的业务层，然后是 UI。

我不想为此使用任何实用程序。

在这方面的任何帮助将不胜感激！

我经常在 PHP，特别是 WordPress 插件中看到人们直接在他们的插件中编写 SQL ...我学到的东西的方式，一切都应该分层处理......所以如果有一天给定层的要求发生变化，我只需要担心改变所有接口的层。

现在我正在编写一个层来连接数据库，这样，如果我与数据库交互的方式发生了变化，我所要做的就是改变一个层，而不是我创建的 X 个插件。

我觉得好像这是其他人过去可能遇到过的事情，而且我的方法效率低下。

我正在写课程，例如

这允许我使用给定对象创建数据库表、列和行，并使用特定方法来处理它们的所有功能：

我的问题是...

其他人是否已经写了一些东西来提供不同层之间的一些分离？

如果没有，从长远来看，我的方法是否会有所帮助，或者我是否在浪费时间？我应该像其他人一样分解和硬编码sql吗？

如果它有助于我自己写这篇文章，有什么方法可以让我更有效地处理它吗？

我正在尝试使用 Entity Framework 可视化 3 层设计。

如果我在 EF 上下文之上有一个存储库，它们是否都是数据层的组件？

还是存储库是数据层本身，而 EF 是其他东西？

我将有一个与存储库或数据层通信的 BLL（我不知道..），我试图弄清楚这一切是如何结合在一起的。

我很欣赏安全被视为一个跨领域的关注点，在我目前的开发中，我已经将我的安全构建为一个独立的组件，可供我的各个层使用。在我的安全组件中，有一个数据访问层用于检索用户、组等。

但是，当它在再次拥有自己的数据层的应用程序中使用时，将这个数据层与安全组件一起使用对我来说似乎并不合适。

我错了吗？

我正在创建 n 层应用程序架构。不同的层对彼此的内部实现一无所知，层之间的通信通过非常狭窄的接口处理，并辅以 IoC/DI。

现在我将业务对象（在业务层中定义）传递给数据层。业务层本身不知道数据的实际保存方式和位置（通常是数据库，但业务层不应该知道）。业务对象通过 IDataReader 的实现传递到数据层（这种方法还支持在未来的场景中批量加载数据）。数据层从 IDataReader 读取所有数据并调用一些存储过程将数据保存到数据库（如果保存一个对象，IDataReader 返回“一行”）。

实际问题在这里：

因为我只是将 IDataReader 传递给数据层并将数据与其类型断开连接，所以在这种情况下确定数据位置的最佳方法是什么？

例如，如果我将“用户”类型的实际业务对象传递给数据层，那么数据层应该将数据保存到表“用户”中。在其他一些情况下，数据可能会独立于业务层中的类型保存到一些不同的结构中。

在当前实现中，我将业务对象的类型信息传递到数据层，数据层检查此类型并决定将数据放置在何处。

数据层检查传入数据并确定其位置是正确的解决方案，还是数据层应该公开可以保存数据的“位置”列表（枚举？）？

提前致谢！

/澄清：

我在这里看到的选项是： 1. 数据层给出可以保存数据的“plces”列表 2. 数据层检查给定的参数（如类型 arg）并决定存储数据的位置

第一选择惩罚；如果我尝试将“产品”类型的业务对象存储到“用户”类型通常使用的结构中怎么办？

第二选择罚分；我必须将类型“Namespace1.Namespace2.User”映射到将其数据保存到表“User”的特定例程。所以手动为每种类型做一些映射......

/澄清2：

现在我确实像这样检索：

所以我将 typeof(Catalog) 传递给数据层......所以我在数据层中有类型信息。

现在在数据层中，我需要选择努力从数据库中获取数据的“适配器”。我可以编写巨大的 if/switch 结构来选择适配器……这令人沮丧。我也可以编写属性并像这样使用它：

然后我有从给定类型映射到属性值的代码......

...但是对于硬编码的类型字符串来说有点臃肿和问题...

有什么建议么...？

/澄清3

我知道这个系统可以通过“可插拔业务模块”进行扩展。这些模块包含基本业务逻辑不知道的业务对象（和一些逻辑），数据层也完全不知道“插入程序集”中包含的这些业务对象。这个外部业务模块没有引用基础业务层或数据层。当保存来自此外部程序集的业务对象（=发送到数据层）时，数据层默认将其保存为 EAV 样式（http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80% 93value_model) 数据结构自动。因为这种数据结构可能存在一些性能问题，数据层必须有办法将特定的业务对象类型保存在自己专用的数据结构中（通常是与该类型一一映射的表）。

这里的想法是，我可以创建许多新的业务对象，并且可以将它们全部保存到数据层，而无需实际对数据层进行任何编码！以后如果需要，我可以为选定的业务对象创建自己的专用数据结构。