问题标签 [n-tier-architecture]

所以我有一个 MVC 应用程序，在另一个项目中，我有一个普通的类集合，用于处理应用程序的业务和数据逻辑。我在 MVC 项目本身的模型中也有一些逻辑。此逻辑处理 ViewModel 等，这些事情在 n 层项目中无法完成，因为它们与 MVC 项目本身相关并且需要在同一个项目中。

我的问题是：

• 我的模型类是否应该了解 n 层业务逻辑？还是应该只有控制器拥有这些知识并根据需要在 n 层应用程序和 MVC 模型之间来回发送数据？
• 如果我的模型可以引用 n 层应用程序，那么我的控制器是否应该通过模型类访问 n 层？

希望这是有道理的，发现很难正确地表达我的观点。

权限逻辑应该在 MVC 的哪一层（模型、视图、控制器）处理？

让我澄清一下。显然，UI（视图和控制器）需要能够访问权限以显示/隐藏组件并处理权限被拒绝的情况。很明显，权限应该由模型层持久化到数据库中。

但是像这样的“复杂”权限规则呢？
在我正在开发的 wiki/CMS 系统中，每个用户都有一组每页权限（查看、编辑、重命名等）。对于现有页面，这些权限是从数据库中检索的。对于新页面，假定用户拥有所有可能的权限（当他们创建/编辑它时）。

另一个例子是页面列表：
当前用户应该只能看到他们在页面列表中具有查看权限的页面。

控制器应该处理这个逻辑吗？还是应该 Controller 只负责调用 GetPermissions() 方法（或 GetPageList），而填充它的所有逻辑都在 Model 中处理？

带有很多控件和验证的网页。我需要允许用户将应用程序保存到数据库中。

我有一个名为 Customer 的主表和 5 个不同的子表，其中 Customer_ID 是外键。

一旦用户点击保存，我需要在客户表中插入一条记录，然后将记录插入到具有刚刚创建的 customer_ID 的相关子表中。

你们能不能给我推荐一个上面提到的场景的一个很好的例子，这会有很大的帮助。

我为 Customer 和所有子表创建了一个模型。但我真的不知道如何从这里开始。

我正在使用 VB.net 和 ASP.net 2.0 和 oracle 8g。我们不能使用 ASP.net 3.5 或 MVC 1.0。

请帮忙

万分感谢。

我将很快设计几个 Web 应用程序。它们可能会在 asp.net mvc 中完成。

在我现有的 web 应用程序中，使用 delphi 完成，数据访问层被分离成一个完全独立的应用程序，有时运行在不同的服务器上。这样做更多是为了代码重用，而不是出于架构原因。这不会成为下一个应用程序的一个因素，因为它将是全新的。

在 mvc 应用程序中使用单独的数据访问应用程序是否过大？我已经通过使用 MVC 分离出业务类，并且我将使用 ORM 来执行数据库持久性。

编辑：只是为了澄清；我使用术语层来指代单独的物理应用程序，而不仅仅是逻辑分离或层。

我最近一直在设计相当多的 Windows 窗体应用程序（数据输入应用程序、办公集成等），虽然我一直在设计时考虑到逻辑层，但“中间层”业务逻辑层一直托管在台式PC（即物理客户端-服务器）。

当我处理更复杂的应用程序时，我发现自己渴望使用物理中间层，桌面客户端将请求传递回应用程序服务器以处理业务逻辑（可能会定期更改）和接口。感觉就像我错过了 Web 应用程序更原生的可伸缩性和可维护性等因素。

我很想知道其他 WinForms 开发人员在他们的中间层分离方面走了多远：

• 您在中间层服务器上执行多少处理（如果有）？
• 您使用什么通信方法 - WCF、远程处理、Web 服务等？
• 性能在多大程度上是一个因素，您多久往返一次服务器？

将业务逻辑移到单独的层是否有好处，或者将组件本地托管在 PC 上是否更实用（并且只需确保您有一个良好的部署模型来随着业务规则的变化推出定期发布）？

或者，如果涉及这些因素，我是否应该完全引导客户远离 WinForms？有了 Silverlight 甚至 ASP.NET w/AJAX 等替代方案，选择 WinForms 客户端的理由似乎越来越少。

Recently I have been debating on the best way to handle communication up the chain in n-tier architecture.

Currently the methods I am doing is throwing and handling exceptions between layers for errors, and using events/delegates for other communication (to update progress bars and such). Are these the best way or is there another method that I have overlooked that would be considered better practice?

我们中的许多人从头开始设计和开发系统，都曾遇到过必须对项目架构做出艰难决定的情况。你在哪里，或者你会在哪里划定界限，以建立一个架构合理且可扩展的系统的“下一步”？

我建立了一个大型网站，在架构方面相当崩溃。有一个带有前端代码的 Web 层，然后是处理要完成的实际工作的业务和数据层。不同的逻辑分离层共存于同一台物理机器上。通过使用 Web 服务层/层，可能已经存在物理分离，甚至简单的逻辑分离。由于各种原因，它没有以这种方式实施。决定是对还是错只是一个见仁见智的问题。从我的角度来看，我曾遇到过一些相对简单的应用程序被过度设计的情况。

在为新项目设计架构时，您会考虑哪些因素？您是否有经常使用的一致项目设计，您是从一开始就采用 n 层，还是在每个项目进入时进行评估？

反复经历这些经历，我常常想知道处于相同位置的其他人如何证明并做出这些考虑。我相信我们都会有不同的意见，但我相信理解这些意见背后的思维过程会很有启发性。

我需要一些帮助来很好地组织我的数据模型。
我正在编写一个应用程序，它将是一个简单的笔记本。我使用三层架构 = 业务逻辑、数据逻辑、数据库访问。
我想使用标签系统，这样在应用程序中搜索信息会更容易。这里有几个问题
- 由于关注点分离，实体类和支持通过这些实体进行标记搜索的类必须不同。那么，最好的方法是什么 - 封装或继承？
- 将实体类与检索并向数据库提供信息的类分开是个好主意吗？如果是，它将是 4 个级别 - 实体类、数据库类、标签搜索助手和 BL 类。

我的网络解决方案中有以下结构：

• 领域
• 数据访问
• 应用服务
• 网络
• 测试

我有一些应用程序服务用于抽象我正在使用的一些 Web 服务。（具体来说，我将一些交付的 Web 服务捆绑到一个应用程序服务中。）我的应用程序服务层是否应该引用我正在使用的 Web 服务，而其他层仍然无知，或者我应该引用 Web 和测试中的 Web 服务层并将 Web 服务注入应用程序服务？

我正在拆分我目前拥有的现有工作应用程序，以便更好地理解 n 层结构。此应用程序使用带有表单身份验证的自定义成员资格和角色提供者。

目前所有的数据访问和业务逻辑都在同一个 ASP.Net 解决方案中。

我已经构建了一个业务逻辑层 (BLL) 和一个数据访问层 (DAL)，并且我正在提取业务逻辑。我正在为 MembershipProvider 类应该存在的位置而苦苦挣扎。

• 由于使用这些类的内置 UI 控件（登录、创建用户向导等）的紧密耦合，成员资格提供程序类是否必须驻留在表示层中？

• 它们可以存在于 BLL 中吗？如果是这样，我如何从演示文稿中引用它们？一旦从 UI 中引用 BLL，是否只是将 web.config 更改为指向 BLL.membershipprovider 的问题？

只是在我走错路之前尝试寻找健全性检查。不幸的是，我无法通过谷歌找到任何这样的例子。任何帮助/指针表示赞赏。