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.