如何在ASP.NET中组织数据访问层（DAL） [英] How to organize Data Access Layer (DAL) in ASP.NET

问题描述

我有一个用C＃开发的ASP.NET Web窗体应用程序。

I have an ASP.NET Web Forms application developed in C#.

我想通过将DAL任务与后面的代码分开来构造应用程序的结构。

我在App_Code中创建了一个类， DBUtilities ，该类负责与数据库的通信，以免在整个应用程序中重复代码。该类具有获取数据表，标量值等的方法，并且它们接受连接字符串名称和查询命令作为字符串作为参数。

I created a class in App_Code, DBUtilities that takes care of the communication with the database, in order not to have duplicated code all along the application. The class has methods to get datatables, scalar values, etc... and they accept as parameters the connection string name and the query command as string.

问题是我的代码中仍然保留了所有查询命令。他们中的许多人在页面上都是重复的，这会导致维护问题。

The problem is that I have still all the queries' commands in my code behind. Many of them are duplicated all around the pages and this cause maintanance problems.

我想知道创建一个（静态）类 QueryRepository 是否包含许多字符串属性是否是一个好习惯？ >，并将它们关联到每个特定的查询命令。每次我想执行查询命令 MyCommand 时，我都会将 QueryRepository.MyCommand 属性插入的 DBUtilities 类。串。 Morevoer如果需要更改查询命令，可以在QueryRepository类上执行。

I was wondering if it is a good practice to create a (static) class QueryRepository that contains many string properties and associate to each of them a specific query command. Everytime I want to execute the query command MyCommand I pass to the DBUtilities class the QueryRepository.MyCommand property instaed of the string. Morevoer if I need to change a query command I do it just on the QueryRepository class.

这是组织DAL的好方法吗？

Is it a good way to organize my DAL?

推荐答案

对于实现Model-View-Presenter（MVP）模式的ASP.NET Web表单，可以是一种分离逻辑的好方法以及来自后面的UI代码的数据库查询。您必须编写一个Presenter类，该类具有对视图接口的通用引用，并具有其中具有数据库查询，逻辑等的模型。presenter将在其所有功能中调用通用视图接口的功能。然后，您可以编写实际的ASP.net视图。在视图中，您实例化并引用此演示者，并在实例化演示者时将自身对象（即ASP视图本身）（使用 this关键字）注入到演示者中。您可以根据需要为演示者类设计适当的继承，以便可以重用它们并可以进行单元测试。

For ASP.NET web forms implementing Model-View-Presenter (MVP) pattern can be one good approach to separate your logic and database queries from the UI code behind. You have to write a Presenter class that has a generic reference to a view interface and has a model in it which has database queries, logic etc. The presenter will call functions of the generic view interface in all its functions. Then you can write the actual ASP.net view. In the view you instantiates and reference this presenter and while instantiating the presenter you inject the self object i.e the ASP view itself (using "this" keyword) to the Presenter. You can design proper inheritance for your presenter classes based on your need so that they are reusabe and can be unit tested.

为响应CiccioMiami的查询而添加的内容：

这里有几个链接可以开始

Here are couple of links to start

http://www.codeproject.com/KB/aspnet/AspNet_MVP.aspx

http://wiki.asp.net/page.aspx / 340 / mvp-pattern /

此处说明了MVC和MVP模式的区别： http://www.codeproject.com/KB/architecture/DotNetMVPFramework_Part1.aspx

The difference in the MVC and MVP pattern is explained here: http://www.codeproject.com/KB/architecture/DotNetMVPFramework_Part1.aspx

此外，对于ASP.net Web表单体系结构，请求与页面生命周期紧密相关。您有一系列页面生命周期事件，开发人员在每个这些事件中编写代码。因此，业务逻辑紧密耦合到UI视图。在一段时间内，这对于代码的可维护性和单元测试来说不是一个好的情况。在ASP.net Web表单中，单元测试很困难，因为很难模拟请求和页面生命周期事件。在MVC中，请求首先到达控制器。控制器将模型用于业务逻辑，并将模型传递给视图。该视图使用模型数据进行渲染，并作为对用户的响应返回。控制器可以更好地控制工作流程。您可以像在独立应用程序中一样测试模型，DTO传输等。使用Web表单时，没有控制器，该请求直接进入ASP.net页面（即视图）。用户无能为力。很好，Microsoft意识到了这个问题，我们有了ASP.net MVC。 ASP.net Web窗体的MVP模式将在某种程度上解决代码分离问题。最好的选择是使用ASP.net MVC，否则可以将MVP与Webforms一起使用。

To add to this, for ASP.net Web form architecture, the Requests are tightly coupled with the page life cycle. You have series of page life cycle events and developers write code in each of these events. Thus the business logic becomes tightly coupled to the UI view. Over the period of time this is not a good situation for code maintainability and unit testing. Unit testing is difficult in ASP.net web forms as it is difficult to simulate the requests and page life cycle events. In MVC the requests first comes to a controller. The controller uses the model for business logic and passes the model to view. The view renders using the model data and is returned back as the response to the user. The controller has greater control on the work-flow. You can test the model, DTO transfers etc. as you could do in a standalone app. With web forms there is no controller the request directly comes to ASP.net page which is a view. There is nothing much user can do. Good that Microsoft realized this problem and we have ASP.net MVC. The MVP pattern for ASP.net webforms will solve the code separation problem to some extent. The best option is to use ASP.net MVC if not then you can use MVP with Webforms.

这篇关于如何在ASP.NET中组织数据访问层（DAL）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！