问题标签 [multi-tier]

最初有我的 BO 调用信息然后传递给 UI 的 DAL 对象。然后我开始注意到 UI 中的代码减少了，并且有 Controller 类。有什么好的推荐。

我目前正在构建我的

然后我有控制器类（最近实现了这种风格）

然后在我的应用程序中

我最初发现使用共享类时，我不必在需要获取数据时继续创建 DAL 的新实例

你怎么看？

谢谢

我有一个 Web 应用程序，它大量使用会话状态来存储有关当前用户、他们的个人设置、记录他们的会话历史等的信息。

我发现自己在业务层中检索此会话信息，如下所示：

这带来了一个问题——在未来的某个时候，我的应用程序将有一个 Windows 客户端，它显然无法引用 Web 会话状态。因此，我需要一个可以在业务层中引用的主机或自定义会话类，它与应用程序是在 Web 上运行还是在桌面上运行无关。就像是：

在幕后，Web 实现显然会利用 Session 状态来存储信息，但我需要将其隐藏在业务层之外。有没有人解决了这个问题或得到任何关于如何最好地解决这个问题的实用建议？

帮助表示赞赏。

我最近看到很多开发人员的职位发布，其中包含一个或多或少这样的句子：“必须具有 N-Tier 架构的经验”或“必须能够开发 N-Tier 应用程序”。

这让我问，什么是 N-Tier 架构？一个人如何获得经验？

我对 MVC 和多层 Web 架构的概念很陌生。我开发了一个 PHP 应用程序，并且正在使用一个可用的 MVC 框架。我的问题如下：

据我了解，MVC 本身并不被视为多层架构。我可以理解单独使用 MVC 如何比采用非结构化方法更上一层楼，但我正在考虑如何适应简单的 3 层架构？MVC 会驻留在表示层吗？添加分层方法的优点是什么？据我所知，仅使用 MVC 就没有明确的数据对象负责从数据库中检索数据，这通常被填充到模型中。同样，在 3 层架构中的业务逻辑将驻留在“业务层”（或任何您想调用的名称）中，可以填充到控制器中。

我的理解有些正确吗？我知道我问了很多问题，但我想听听您讨论如何将 n 层架构整合到您的 MVC 框架（PHP 或其他）中，因为我认为这两者并不相互排斥。谢谢！

我有一个 .NET Winform Click-Once 部署的胖客户端，它与三个数据库、2 个 SQL Server 数据库和一个 Oracle 数据库通信。

第一个 SQL Server 数据库，我将调用 Master。我想向主数据库添加更多表和列，但我被告知我不会被授予这样做的权利，这是不可协商的。因此，我决定添加一个新的 SQL Server 数据库，我将其称为 Extensions 数据库来存储我想放置在 Master 中的其他信息。

由于我无权将 Extension 数据库与 Master 放在同一台服务器上，因此我在另一台服务器上创建了 Extension db，并创建了从 Extension 数据库服务器到 Master 数据库服务器的 db 链接。这使我能够执行跨越两个数据库的查询。我还有第三个数据库，一个 Oracle 数据库，我偶尔会连接到它。

因为我认为连接到 Oracle 数据库需要安装 Oracle 驱动程序，这不太可能在最终用户的 PC 上，所以我决定让 WinForm 客户端调用 Web 服务，Web 服务会返回结果。为了保持一致性，因为我的直觉告诉我应该从一个地方执行数据库访问操作，所以当胖客户端需要与 SQL Server 数据库通信时，我采用了相同的方法，即它们通过 Web 服务。

现在我质疑我是否因为首先必须调用 Web 服务器然后让 Web 服务器调用数据库而不是在胖客户端中打开用户 PC 上的连接并直接连接到而对性能造成太大影响SQL Server 数据库。请注意，我所指的应用程序是一个非官方的实用程序，需要访问这三个生产数据库，但不允许在生产中实际运行，所以我怀疑我的开发 Web 服务器和生产数据库之间的正常高速管道不要在这里申请。

为了获得最佳性能，我的 Winform 应用程序是否应该直接与 SQL Server 数据库建立连接？有哪些取舍？

今天是否仍然需要额外的驱动程序来连接到 Oracle 数据库，或者现在所有这些都在 .NET 框架中，如果我愿意，我也可以直接连接到 Oracle 数据库？

此外，我发现使用链接服务器比创建两个单独的数据库连接并将数据集中在一起要慢。当我启动两个异步查询然后将数据组合在一起时，我得到了最好的结果，就好像它是由一个使用数据库链接的查询返回的一样。但是，这会导致维护问题，并让我在需要修改跨数据库的 SQL 连接时后悔这种方法。

我对 PHP 比较陌生，但在具有 SOA 架构和多层应用程序的复杂企业环境中经验丰富的 Java 程序员。在那里，我们通常会在中间层实现具有业务逻辑的业务应用程序。

我正在编写一个替代货币系统，该系统应该易于个人和社区部署和定制；它将是开源的。这就是为什么 php/mysql 似乎是我的最佳选择。

用户有账户，他们得到余额。此外，系统根据提供的总服务和总可用资产计算价格。

这意味着，在购买时会发生一系列计算；余额和总数得到更新；这些是派生的数字，通常不会放入数据库中。

尽管如此，我还是将触发器和存储过程放入数据库中，因此在 php 代码中没有进行这些更新。

人们怎么想？这是一个好方法吗？我的经验告诉我，这不是最好的解决方案，并促使我实施中间层。但是，我什至不知道该怎么做。另一方面，到目前为止，我所拥有的 store procs 对我来说似乎是最合适的。

我希望我把我的问题说清楚了。所有评论表示赞赏。可能没有“完美”的解决方案。

I have a specific question, that could use a general answer... When building Multi-Tier applications in PHP, does everything have to be done in the Business Logic layer, or can any layer do work... Example, Lets say I'm building an application that shows user information (from the database) on the presentation layer. Should I use the business layer to simply pass the data to the presentation layer, or just get the information from the database directly within the presentation layer. Should the presentation layer be used JUST for presenting the data, the accessor layer used JUST to get the data, and all the work be done in the business layer?

Also, speaking of the different layers, is it best to do things procedurally, or using OOP ( like using includes to show the templates vs using a class to include the templates, validating data procedurally vs using a class, or functions vs classes for getting the data from the database, etc. )

As you can see, I'm trying to understand how things work, and the best way to do things. That being said, if you have any advice, or any general tips on the subject... please leave them..

Thanks

在多层应用程序上，我需要模拟各种 TCP/IP 错误来测试一些重新连接代码。有谁知道我可以为此目的使用的任何工具（基于 Windows）？谢谢。

仅关于关注点的分离，对于具有用户界面层、业务逻辑层和数据访问层的多层应用程序，使用 ASP.NET MVC 而不是 ASP.NET webforms 是否有优势？

我有一个多层应用程序，它以所有数据访问的存储库模式开始，并将 IQueryable 返回到服务层。包含所有业务逻辑的服务层将 IList 返回给控制器（注意：我将 ASP.NET MVC 用于 UI 层）。在数据访问层返回 IQueryable 的好处是它允许我的存储库非常简单，并且可以延迟数据库查询。但是，我在我的服务层中触发了数据库查询，以便我的单元测试更可靠，并且我没有让控制器灵活地重塑我的查询。但是，我' 最近遇到了几种情况，将查询的执行推迟到控制器会显着提高性能，因为控制器必须对特定于 UI 的数据进行一些预测。此外，随着 oData 之类的出现，我开始怀疑端点（例如 Web UI 或 Web API）是否应该直接与 IQueryable 一起工作。你怎么认为？是时候开始将 IQueryable 从服务层返回到 UI 层了吗？还是坚持使用 IList？你怎么认为？是时候开始将 IQueryable 从服务层返回到 UI 层了吗？还是坚持使用 IList？你怎么认为？是时候开始将 IQueryable 从服务层返回到 UI 层了吗？还是坚持使用 IList？

这个线程在这里：返回 IQueryable<T> 或不返回 IQueryable<T> 似乎保证将 IList 返回到 UI 层，但我想知道是否由于新兴技术和技术而发生了变化。