How a Get method in Asp.Net works?

It works something like this when your db context is injected (and you use AutoMapper)

public IEnumerable<MainScreenSlideDefinition> Get(string type) {
    return db.SlideDefinition.Where(s => s.Type == type).ToList().Select(s => Mapper.Map<MainScreenSlideDefinition>(s));
}

or like this if it is not

public IEnumerable<MainScreenSlideDefinition> Get(string type) {
    using(var db = new OgreContext())
        return db.SlideDefinition.Where(s => s.Type == type).ToList().Select(s => Mapper.Map<MainScreenSlideDefinition>(s));
}

Simple.

But why make a MainScreenSlideDefinition model at all? Why not return SlideDefintion directly?

Not a bad question.

So long as SlideDefinition is easily serializable you absolutely can. However, I find that its important to think explicitly about what is sent across the wire and an explicit model is an obvious way to do it. Every time I've ever started out returning entities I've refactored it later. That being said, it's not a difficult refactoring so maybe go ahead and return entities until it another concern becomes more prominent.

These models are very simple by the way. Like this:

public class MainScreenSlideDefinitionModel {
    public int Id;
    public string Name;
    public string Type;
    ...
}

I prefer fields to properties since ... well, since less code is better than more code, the difference is not terribly important. However, fields are not auto-mapped correctly.

Fially, I don't know if you've come to this conclusion yourself, but it's something that causes large enough issues that I always make a point of mentioning.

Never use the same type for an output model (which becomes the response) and an input model (which goes through model binding to turn a request into a parameter).

It's just....not a good idea. Input models and output models always start the same and deviate quickly in what they want to take in and write out. If you share models you'll end up hacking around this and strongly coupling two pathways that are really completely independent.

But, you ask, doesn't that generate more code and don't you hate code? Well yes...but not much more. This is a perfectly reasonable use of inheritance.

public class SlidesController {
    public IEnumerable<MainScreenSlideDefinition> Get() {
        ..
    }
    public class MainScreenSlideDefinition : SlideDefinitionModel {}

    public IHttpActionResult Post(CreateSlideDefintion sd) {
        ..
    }
    public class CreateSlideDefintion : SlideDefinitionModel {}

    public IHttpActionResult Put(ModifySlideDefinition sd) {
        ..
    }
    public class ModifySlideDefinition : SlideDefinitionModel {
        public int Id {get; set;}
    }

    ..
    public abstract class SlideDefinitionModel {
        public string Name { get; set; }
        public string Type { get; set; }
    }
}

Note that I embed my models as inner classes in the controller because...well, if they're simple and not reused, why not put them alongside the code that uses them? A shared Models folder makes sense for code that is shared (even then I'd argue it should be Controllers.Models). Otherwise, follow the princple of high cohesion and keep code that is likely to change at the same time together. Admittedly, this is an unusual opinion but I'm like 80% sure I'm correct on this and everyone else is wrong.

So there you go. Lots of opionions. I hope that's what you were asking for.

togakangaroo/gist:2c1433c1710a0143e214

How a Get method in Asp.Net works?