Good point! I have been getting away from creating repositories. It's one less layer I need - although as I think about it, there probably are benefits to keeping all the low level database interactions in one cohesive unit. I kind of went through a phase of excessive decoupling long ago. Guess I never re-evaluated my opinions on repositories. I think either approach is fine in the end.
I find it a little overkill for a .NET MAUI app. In most cases, your app will connect to a SQLite DB, so no need to abstract up to EF. I feel like this SQLite package has everything I need in terms of an ORM, and it is much simpler than EF. I'm sure EF could work as well though.
Sqlite as a file format has always been an interesting idea for me
Is it really necessary to have Dto and Model when they are exactly the same?
For a simple domain, it's probably fine to use the same object!
You always have such great content. Was surprised that you didn't use a repository. Are you getting away from that?
Good point! I have been getting away from creating repositories. It's one less layer I need - although as I think about it, there probably are benefits to keeping all the low level database interactions in one cohesive unit.
I kind of went through a phase of excessive decoupling long ago. Guess I never re-evaluated my opinions on repositories. I think either approach is fine in the end.
@SingletonSean I'm really getting into vertical slices. Features folders with a shared folder. Seems to work really well.
Why don't you just use Efcore?
I find it a little overkill for a .NET MAUI app. In most cases, your app will connect to a SQLite DB, so no need to abstract up to EF. I feel like this SQLite package has everything I need in terms of an ORM, and it is much simpler than EF. I'm sure EF could work as well though.
Nice video. Wouldn't it be better to move the crud methods to a helper or service class?
Definitely! A service class that returns the Ticket domain object would be ideal
Database integration