问题标签 [n-layer]

我正在使用 TableProfileProvider 在 n 层架构中使用 ASP.NET 配置文件系统。
UI 层是一个 Web 应用程序，因此我必须公开 profilecommon 类才能使用配置文件。
这是我的架构的简化架构：
UI： ASP.NET Web 应用程序。
BusinessEntities：纯 POCO 类。坚持不懈。
BLL：业务逻辑层。
DAL：数据访问层。

Profilecommon 的定义是：

在一个简单的设计架构中，所有内容都在 Web 应用程序项目中定义，我将按如下方式访问 profilecommon：
ProfileCommon strongleyTypedProfile = (ProfileCommon)this.Context.Profile;

我希望能够从我的业务逻辑层访问 Profile Common，因此我将 ProfileCommon 定义移至我的 BusinessEntities 库（必须在 BusinessEntities 库中添加对 System.Web 程序集的引用）并定义了新的 ProfileBLL 类：

现在我可以像这样从 UI 访问常见的配置文件：

现在，在业务层/业务实体库中引用 System.Web 是否违反了 n 层架构规则？如果是这样，您会提出什么建议来实现这一目标？

我正在尝试构建一个 Web 应用程序，让管理员通过 C# 与数据库对话并添加新的表和列以满足他的要求（有点像一个非常简单的数据库工作室），但我不只是想创建一些意大利面条应用程序.

所以我试图弄清楚当他创建表并使用表来构建它们时如何动态地（自动地）让这些东西：

1-业务对象或实体（类，它的对象和属性）。2- 数据访问层（连接到数据库和添加、更新、删除检索项目（对象）的一些简单方法）。

这可能吗 ？关于如何实现它的任何指示？

编辑

刚打开你的链接！！..它在谈论数据绑定控件和东西！..我的问题比这更高级！当您构建 N 层应用程序时，您从数据库架构和实现开始，并且很容易以编程方式完成，然后您开始构建 DAL 类（添加、编辑等，换句话说，CRUD 操作）并形成这个数据库

我想要做的是允许网络管理员选择通过我的应用程序添加新表，然后 - 动态地 - 应用程序将表名称和列作为参数并创建新类并在其中定义将实现的 CRUD 方法SQL CRUD 操作

然后它还将动态创建类并在其中定义变量、属性和方法以调用和使用 DAL 方法..所有这些都基于表、列名

注意：所有这些都发生在运行时！

N 层 ASP.NET 应用程序：我的所有层使用一个类库，还是每一层使用一个类库？

我一直听说 3 层方法（演示 + 业务逻辑 + 数据访问），这就是我一直工作的方式（如果我计算数据库本身，则添加“4”层），但我想知道这是否是关于层和层架构（我已经知道层和层之间的区别），是否有 5 层以上的方法？我也听说过控制器、服务和应用层，这如何适应上下文？

谢谢，

在一个 n 层（比方说 5 层）的应用程序中，如果某个操作可以选择绕过其中一个层并直接与下一层通信，那么它仍然可以称为“n 层”架构吗？ ，还是变成（n-1）层（4层）架构？

您可以绕过的相关层是否应该被视为“层”？

编辑：我正在尝试实现具有以下结构的应用程序 -
表示层（包含 WPF 网格）
应用程序层（包含应用程序逻辑和工作流作为应用程序服务，从域模型对象中提取显示模型对象，然后将其绑定到 UI 网格)
领域层（仅包含领域模型对象）
存储库（存储从数据库中获取的数据，将下层与上层隔离）
数据映射层（将领域模型对象映射到数据模型对象）
数据访问层（包含数据模型对象，并在数据库中存储和检索数据）
- 上面的每一个都是作为单独的项目实现的，领域层由应用层、存储库和数据映射层引用。现在的问题是，应用程序层直接与存储库通信，而不是通过域层和域层（如果我可以称之为层的话）就像一个横切参考。所以这就是我的问题所在，我应该将其称为域“层”吗？我想不是。但是在领域驱动设计中存在领域层，对吧？我的架构一定有问题吗？它在哪里，是什么？

n 层架构中的 Asp.net 应用程序（最好是 DDD 架构）。

在表示层中，我有一个网格（比如说telerik radgrid 或标准gridview），我需要在其中显示产品列表（产品是我的实体）。

谈论网格的 Linqdatasource 提供程序有意义吗？在这种情况下如何使用它？或者我应该“手动”编写绑定操作（拦截绑定事件并从我的应用程序层调用我的 getproductlist 函数？

欢迎示例...谢谢。

我将开发一个相当大的winform项目。我打算使用实体框架作为 ORM 工具。现在我正在寻找一种架构（MVC/MVP/MVVM 等）来实现所有这些。首先，Windows 窗体的 n 层架构选择很少，而且我得到的大多数都是在 EF 进入市场之前编写的。我从 codeplex ( http://rocketframework.codeplex.com )得到了一个名为 Rocket Framework 的框架

我环顾四周，但怀疑它能否满足广泛的要求。如果有人已经发现了轮子，请指导我。此外，如果 EF4 之前的现有架构可以容纳它，那么我也可以尝试一下。请出主意！

我正在阅读很多架构（N-Layered 和 DDD），但大多数文章都是关于网站架构的，并且主要开发 Windows 服务。
架构可以以同样的方式使用吗？

所以，我在这里查看了一些关于规范模式的帖子，但还没有找到答案。

我的问题是，在 n 层架构中，规范究竟应该在哪里“更新”？

1. 我可以将它们放在我的服务层（又名，有时称为应用程序层......基本上，一个 .aspx 代码隐藏会与之交谈的东西），但我觉得这样做，我让业务规则泄露出去域。如果通过其他方式访问域对象（除了服务层），域对象就不能强制执行它们自己的业务规则。

2. 我可以通过构造函数注入将规范注入我的模型类。但同样，这感觉是“错误的”。我觉得应该注入模型类的唯一东西是“服务”，如缓存、日志记录、脏标志跟踪等......如果你能避免它，使用 Aspects 而不是乱扔模型的构造函数具有大量服务接口的类。

3. 我可以通过方法注入（有时称为“双重调度”？？？）注入规范，并明确地让该方法封装注入的规范以强制执行其业务规则。

4. 创建一个“域服务”类，它将通过构造函数注入获取规范，然后让服务层使用域服务来协调域对象。这对我来说似乎没问题，因为规范强制执行的规则仍然在“域”中，并且域服务类的命名非常类似于它正在协调的域对象。这里的事情是我觉得我正在编写很多类和代码，只是为了“正确”实现规范模式。

除此之外，有问题的规范需要一个存储库才能确定它是否“满意”。

这可能会导致性能问题，尤其是。如果我使用构造函数注入 b/c 消费代码可以调用一个可能包装规范的属性，而这反过来又调用了数据库。

那么有什么想法/想法/文章链接吗？

新建和使用规范的最佳地点在哪里？

我正在使用 ASP.NET Web 表单 C# 从头开始​​创建一个解决方案。

我担心模型对象，因为我不想在每一层中创建重复的模型对象集。在 3 层架构中使用模型对象的最佳实践是什么Web Forms？

我想到的结构如下：

• 用户界面
• BLL
• 达尔
• 模型

模型将包含可在层的每个部分中使用的所有模型类。我认为这会很有用，因为每一层都需要访问模型对象。例如：

1. UI 调用 BLL 中的一个方法，传入一个填充了数据的模型对象。
2. BLL 通过保存在数据库等中的对象调用 DAL 中的方法。

谢谢