Confused about implementation

[ortund]

Granted I'm no expert on development patterns (I usually stick to what gets the job done) but I'm really trying to focus on doing this properly. I loved the article about why we use EF wrong so I decided to implement this instead of the crappy repo pattern I was stuck in.

I'm not clear on implementing to manage my CRUDs though. So just as a learning exercise, I've basically copied the code to build the EfStoreContext and such (basically I copied everything done in the "Better Entity Framework" blog post with the intent of making changes when I understand it better if I need to.

The following methods are ones that I've actually written in my ASP.NET Web Forms app (the boss doesn't want me using anything else - yes, you can feel sorry for me #sadface).

private void LoadCompany(int id)
{
    var data = new DataService();
    var company = data.Service.Companies.Find(id);
    if (company == null) throw new NullReferenceException(nameof(company));

    Name.Text = company.Name;
}

private void LoadCompanies()
{
    // Get a list of Company entities for a DropDownList
    var data = new DataService();
    var companies = from c in data.Service.Companies where !c.Deleted select { c.Id, c.Name }
    CompaniesList.DataSource = companies.ToList();
    CompaniesList.DataValueField = "Id";
    CompaniesList.DataTextField = "Name";
    CompaniesList.DataBind();
}

private async Task<Company> SaveCompany()
{
    var data = new DataService();
    var company = new Company
    {
        Name = Name.Text
    }
    data.Service.Add(company);
    await data.Service.SaveChangesAsync();
    data.Service.ClearCache();
    return company;
}

private async Task UpdateCompany(int id)
{
    var data = new DataService();
    var company = data.Service.Companies.Find(id);
    if (company == null) throw new NullReferenceException(nameof(company));

    company.Name = Name.Text;

    data.Service.Update(company);
    await data.Service.SaveChangesAsync();
}

private async Task DeleteCompany(int id)
{
    var data = new DataService();
    data.Service.Remove(data.Service.Companies.Single(x => x.Id == id));
    await data.Service.SaveChangesAsync();
}

So what I'm confused about is that this still looks very "repo-like" to me in implementation so I'm 99% sure I'm implementing this incorrectly, I'm not clear on how to implement this correctly from the Program.cs included in this git repo.

Some issues I'm aware of right away:

1. I'm not making use of the fact that the DataService class is disposable
2. With the ability to attach entities to the DbContext, I probably don't need to manually map properties.

Could you provide some clarity? Specifically what would these methods looks like in an ideal world based on the use of this code you've provided?

Thanks in advance!

[hoagsie]

This is hard to answer as it speaks directly to how your application is architected. Ideally, what those methods accomplish would fit into application flows. As such, while there may be a distinct method for "DeleteCompany," for example, that should be a natural extension of what the application is doing.

Something you could try to implement and see how it fits would be to embed these sorts of things into your domain objects. This can work particularly well if you have a normalized ID pattern that you can codify into an abstract class. The main benefit is that it lets you isolate what's special about deleting a company versus a user as different types of data often require different treatment. Then your API surface simply becomes DomainObject.CRUDName and you don't need to maintain "LoadCompany" vs. "LoadUser," for example.

The handling of the data service is the only tricky part. In the vast majority of applications I've worked with, the request almost always touches the database somewhere. So, I would be comfortable instantiating a service instance and using DI to tie that instance to a request context. You can then retrieve and use at will. You would need to determine if such a thing would make sense in your application.

These are just a couple thoughts. Let me know if they helped.

[ortund]

Thanks for the feedback :) I love these discussions but I find they very often go well over my head and unfortunately this one is no exception. I'm self taught as I mentioned in my tweet back to you and unfortunately, I've never worked with any of these concepts before so I'm not finding your thoughts as helpful as someone with more knowledge and experience would.

To be honest, I still find myself writing apps where my controller has using blocks for my ApplicationDbContext and then my CRUD operations are done right there directly on the controller. Surely sticking to this would help me keep deadlines at work since it's by far the easiest way to go but I have this eternal desire to improve myself and do better and so here we are.

I've done some reading to help elevate my understanding and I have a rough understanding of what a services should be but as far as domains and dependency injection go, I haven't really looked that up yet. It would be so much easier if Docs had references on these sorts of things though I seem to recall you mentioned even Microsoft don't have their EF documentation quite right to get the most out of EF as it is. Believe that was in the first blog post "You're doing EF all wrong" or such. Loved it by the way.