Thanks for taking the time to respond. Ultimately though, most of those aren't required from the beginning, but the syntactic sugar, abstractions, and performance gains from them are amazing.

You probably already know, but I'll opine a little bit about extension methods. I use them a lot.

Entities > Repositories > Functionality. All split out.

- Entities (pretty much just gets and sets, nothing more than necessary).

- Repositories via extensions to determine where the data comes and goes from (some data comes from SQL, some from Redis, some from Postgres, doesn't matter since it's split out) and any particular queries you need for optimizing things.

- Functionality via more extensions without adding additional code to the entities.

Separation of purpose/use.

I may or may not have completely replaced our data layer in the middle of the height of our season with no interruption. Little bit passionate about this one.

▲

sfn42 4 days ago | parent [-]

Would you happen to have something like a github repo with examples of those repositories? I'd be interested in seeing that.

Personally I'm not a big fan of copious extensions. I use them some times but I'd describe my usage as sparingly.

	▲	marklubi 4 days ago \| parent [-]
		I wish. It's on Github, but my hands are tied and I can't share them since it's someone else's property now (hooray for exits, I think). It's mostly a thought process... I have or need something (entity), lets get data about it (repository/extensions), we need to do something with this now (only extensions). Lots of "static" and "this" involved, but the separation and eventual simplicity makes it worth the effort. Edit: I tried going through some of them to anonymize some for examples, but it felt like treading in dangerous territory.