ASP.NET Web窗体结构 [英] ASP.NET Web Forms Structure

问题描述

我们有我们在几年前提出的ASP.NET Web窗体的解决方案。此溶液具有下列各层：

• 数据访问层：其中我们有访问数据，短短程序像这样的

  公共无效execute_NonQuery_sql（SQL字符串）
  {...}




• 数据实体：在该层我们所定义的不同的实体和查询来访问数据库

   公共静态数据表sel_links（）
  {
      mySQL_DA DA =新mySQL_DA（）;
      字符串sQuery =SELECT标识，名称，网站，总结从链接ORDER BY OrderPos ASC;
      返回da.get_DataTable_sql（sQuery）;
  }
   




• 数据逻辑：在这里我们所说的程序和返回的对象。

  。

   公开名单＆LT; LinksDN＆GT; sel_links_web（）
  {
      尝试
      {
          使用（数据表DT = LinksDA.sel_links_web（））
          {
              清单＆LT; LinksDN＆GT; ListElements =新的List＆LT; LinksDN＆GT;（）;            的foreach（在dt.Rows的DataRow博士）
              {
                  LinksDN元=新LinksDN（DR）;
                  ListElements.Add（元）;
              }            返回ListElements;
          }
      }
      赶上（例外五）
      {
          Ë扔掉;
      }
  }
   




• presentation层：我们有网页。我们叫在逻辑层中的所有程序。

现在我们正在开发一个类似的应用程序，但我们想使用实体框架和模型绑定。
我们使用Visual Studio 2013 Web窗体框架4.5开发。

我们写了很多code的过去，但现在我们看到的是更容易，因为我们没有那么多的code感谢写信给EF

但是我们仍然有几个问题：

1）我们如何构建应用程序？我们需要为图层创建不同的项目？

我们已经看到，我们并不需要有程序来访问数据，因为EF需要的照顾。因此，将它与2层，一个是模式，另一个用于业务逻辑（和presentation层，当然）就够了吗？

2）当您使用EF，你有处置的DbContext？
我们已经看到了这个例子，是正确的？

 公共类LinksBL
{
    ObjectDbContext DB =新ObjectDbContext（）;    公开名单＆LT;链接和GT; GetLinks（）
    {
        返回db.links;
    }    公开名单＆LT;链接和GT; GetLinks（）
    {
        返回db.links;
    }    公共链接GetLink（[查询字符串（ID）INT？LINKID）
    {
        返回db.links.Find（LINKID）;
    }
}
 

3）此外，如果实体链接（例如）有很多的属性，你总是返回所有的性能，即使是你不使用它们？

它可以发生，我们有一个列表，我们只需要3个属性和另一个列表中，我们需要他们。难道我们要创建2个不同的程序，每一个，仅返回，我们将使用属性？
如果是的话，我们怎么能只返回几个属性？

问题可能是太明显了，但我们用于开发不同的方式和EF是新的我们。
感谢您的帮助。

解决方案

  

1）我们如何构建应用程序？我们需要创建
  不同的项目作为图层？

如果你问10个人，他们会回答10个不同的答案。

看开源项目，如 NopCommerce ，的果园或一把umbraco 。的（它们都是MVC，它是很难找到Web窗体项目这些天）的

。

最近，我读到的ASP.NET Web API 2：构建REST服务从开始到结束。它解释了如何创建项目结构，一步一步。 （虽然它的Web API编写，你会得到一个项目是如何布局的想法。）这里是源$ C ​​$ C 。

  

2）当您使用EF，你有处置的DbContext？我们已经看到
  这个例子，是正确的？

您不想实例的DbContext 内部服务类。相反，要使用IoC容器注入的依赖关系。

此外，你不想叫的HttpContext 数据库层中的对象就像你在方法的参数一样。

供参考： 你的情况很相似，依赖注入在.NET本书第2章。在这本书中，马克·西曼介绍紧耦合，以及如何的问题，使用依赖注入来解决。的

  

3）此外，如果该实体链接（例如）具有很多的特性，做
  你总是返回所有的性能，即使是你不使用他们？

有些人喜欢从服务类，而不是IList的或自定义集合返回IQueryable的。
如果IQueryable的，你只能检索所需的属性。

其他想法

如果这是一个新的项目，我想建议使用ASP.Net MVC，而不是Web窗体。原因是你不能单元测试Web表单，它是很难在Web窗体注入依赖关系。

更新：2014年10月8日

  

我们已经使用的WebForms开发和应用程序是相当
  复杂的

我明白了。然而，类库层基本相同;只有presentation层是不同的。主要概念是，你应该能够Web窗体，WPF，MVC，网络API添加到您现有的解决方案，而不改变类库什么。为了做到这一点，你需要注入依赖，而不是紧耦合的（你仍然可以实现Web窗体依赖注入）的。

在事情我忘了提的是要通过信息库访问的DbContext。换句话说，服务层不应该需要知道你使用的是什么样的数据库。

看在回答这些开源项目1。

We have an ASP.NET Web Forms solution we made a few years ago. This solution had the following layers:

• Data Access layer: where we had the access to the data, just a few procedures like this one

  public void execute_NonQuery_sql(string SQL) {...}

• Data Entities: in this layer we defined the different entities and the queries to access the database.

  public static DataTable sel_links()
  {
      mySQL_DA da = new mySQL_DA();
      string sQuery = "SELECT Id, Name, WebSite, Summary FROM links ORDER BY OrderPos ASC";
      return da.get_DataTable_sql(sQuery);
  }
  

• Data Logic: where we call the procedures and return the objects.

  public List<LinksDN> sel_links_web()
  {
      try
      {
          using (DataTable dt = LinksDA.sel_links_web())
          {
              List<LinksDN> ListElements = new List<LinksDN>();
  
              foreach (DataRow dr in dt.Rows)
              {
                  LinksDN Element = new LinksDN(dr);
                  ListElements.Add(Element);
              }
  
              return ListElements;
          }
      }
      catch (Exception e)
      {
          throw e;
      }
  }
  

• Presentation layer: where we had the web pages. We called all the procedures in the logic layer.

Now we are developing a similar application but we'd like to use Entity Framework and Model Binding. We are developing using Visual Studio 2013 Web Forms Framework 4.5.

We wrote a lot of code in the past but now we see is easier since we don't have to write that much of code thanks to EF.

But still we have a few questions:

1) How can we structure the application? Do we need to create different projects as layers?

We have seen that we don't need to have procedures to access the data since EF takes care of that. So would it be enough with 2 layers, one for the Model and another one for the business logic (and the presentation layer, of course)?

2) When you use EF, do you have to dispose the DbContext? We have seen this example, is the correct?

public class LinksBL
{
    ObjectDbContext db = new ObjectDbContext();

    public List<links> GetLinks()
    {
        return db.links;
    }

    public List<links> GetLinks()
    {
        return db.links;
    }

    public links GetLink([QueryString("id")]int? LinkId)
    {
        return db.links.Find(LinkId);
    }
}

3) Also, if the entity Links (for example) has a lot of properties, do you always return all the properties even is you don't use them?

It can happen we have a list where we just need 3 properties and another list where we need all of them. Do we have to create 2 different procedures, one for each, and return only the properties we are going to use? If yes, how can we return just a few properties?

Questions might be too obvious, but we used to develop different way and EF is new for us. Thanks for helping.

解决方案

1) How can we structure the application? Do we need to create different projects as layers?

If you ask 10 people, they will answer 10 different answers.

Look at open source project such as NopCommerce, Orchard or Umbraco. (They are all MVC; it is hard to find Web Form project these days).

Recently, I read ASP.NET Web API 2: Building a REST Service from Start to Finish. It explains how to create project structure step-by-step. (Although it is written for Web API, you will get the idea of how projects are layout.) Here is the source code.

2) When you use EF, do you have to dispose the DbContext? We have seen this example, is the correct?

You do not want to instantiate DbContext inside service classes. Instead, you want to inject dependencies using IoC container.

In addition, you do not want to call HttpContext object inside Database layer like you did in the method parameter.

FYI: you situation is very similar to Dependency Injection in .NET book Chapter 2. In the book, Mark Seemann explains the problem of tight coupling, and how to solve using dependency injection.

3) Also, if the entity Links (for example) has a lot of properties, do you always return all the properties even is you don't use them?

Some people like to return IQueryable from service classes instead of IList or custom collection. If IQueryable, you can retrieve only the properties that you want.

Other thoughts

If it is a new project, I would like to suggest to use ASP.Net MVC instead of Web Form. The reason is you cannot unit test Web Form, and it is hard to inject dependencies in Web Form.

Updated: 10/8/2014

we have been developing using WebForms and the application is quite complex

I see. However, layers of class libraries are basically same; only presentation layer is different. Main concept is you should be able to add Web Form, WPF, MVC, Web API to your existing solution without changing anything in class libraries. In order to do that you need to inject dependencies instead of tight coupling (you can still implement dependency injection in Web Form).

On thing I forget to mention is you want to access DbContext via Repository. In other words, Service layer should not need to know what kind of database you are using.

Look at those open source projects in answers 1.

这篇关于ASP.NET Web窗体结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！