ASP.NET Web Forms Structure

问题

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:

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.

来源：https://stackoverflow.com/questions/26241067/asp-net-web-forms-structure

标签

ASP.NET

entity-framework

webforms