It's not necessary to have a model and a dto. I would just use the model. If your model has properties that will not map to a table column, you can use the [Ignore] decorator. You can use the [Table("")] decorator if you want the actual table name to be different from you class. You can use the [Column("column_name")] for properties.
I use a singleton Database service for interacting with the database. I have all the CRUD operations implemented using generic methods so that one insert method works for any table/class. Same for read, update, and delete. The Database service opens a connection on app startup and can closes the connection when the app quits. That way, there's no need to create a new connection every time you want to interact with the database.
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.
Dear Sean, please slow down a bit during your video. Are you in a hurry or the time is somehow limited? It's ok that you think fast, but place yourself on the listener and/or watcher side - consider yourself on some sort of public event - you probably wouldn't like the fast speech and prefer more or less moderate speed
I'll take it for WPF, thank you very much. Give me your opinion on using MariaDB in LAN applications. Can you give an example of these databases?
Sqlite as a file format has always been an interesting idea for me
How you doing man? last video seems quite outdated. any good, it would be great if I get your new video!
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!
It's not necessary to have a model and a dto. I would just use the model. If your model has properties that will not map to a table column, you can use the [Ignore] decorator. You can use the [Table("")] decorator if you want the actual table name to be different from you class. You can use the [Column("column_name")] for properties.
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
I use a singleton Database service for interacting with the database. I have all the CRUD operations implemented using generic methods so that one insert method works for any table/class. Same for read, update, and delete. The Database service opens a connection on app startup and can closes the connection when the app quits. That way, there's no need to create a new connection every time you want to interact with the database.
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.
Dear Sean, please slow down a bit during your video. Are you in a hurry or the time is somehow limited? It's ok that you think fast, but place yourself on the listener and/or watcher side - consider yourself on some sort of public event - you probably wouldn't like the fast speech and prefer more or less moderate speed