What is the proper way to retrieve and update a custom database object
HardikFefar opened this issue · comments
I have a business requirement where I want to update a custom database object after retrieving it.
so as an example, we have a custom Users table where we store a few fields (UserId as an FK from Member users area) and I want to update those fields (we are using Dapper via repository to retrieve and update the data).
so first I want to retrieve the Users row and then update the fields and then I want to update those changes back to the database, so I took a command to update the Users object but the question is weather the command should receive the UserModel (database table class) or the command should use _domainRepository.ExecuteQueryAsync or any other proper way to retrieve the desired object within the command itself based on the UserId parameter passed in the command?
For Cofoundry entities, you should be retrieving and updating data via the IAdvancedContentRepository. For your own custom tables it's up to you how you work with that data, Dapper certainly is a good option.
I'm not sure exactly what your question refers to, but if it's more about how you wrap up your domain functions, then again that's up to you. You can lean on the patterns we use in Cofoundry with Command and Queries but it's not mandatory and really you should use whatever structure or patterns suit the scale of the problem you are solving or that you and your team are comfortable with.
More specifically, if you are using our CQS pattern, then the aim is really to tailor the command to the thing you want to do e.g. an UpdateUserPreferencesCommand would deal with the specific requirement of updating user preference settings, and I wouldn't try and overload the command by trying to make it do too many things. The properties in the command will only contain exactly what you need to meet the requirement and the code in the command handler can then be tailored exactly to what is needed to execute that command.
Personally I wouldn't use the repository pattern unless you were getting any benefit from it - commands and queries tend to be tailored to specific scenarios so there's not much reusability and I find it often just adds another unnecessary layer, but if it works for you then use it. It's also fine to not use our CQS at all and just use your repository instead e.g. you may feel that CQS is just adding an unnecessary layer to what you already have. Err on the side of simplicity.
Hello @HeyJoel
We are using the Cofoundry architecture and I wanted to follow the approaches taken in there
so I asked how should a command enquire about existing data
let me try to rephrase it, suppose there is a case in Cofoundry where the command needs to update an existing user, how does it first retrieve the data and then update? -- is it like firing a raw query in database with update statement?
Your question seems more related to data access than CQS? Typically in Cofoundry we simply load the entity in EF, edit it and then save it back down via the EF dbContext. There are parts that are not suited to EF such as duplicating a page for example, in this case we shift the logic down to a stored procedure, but you could do the same with a SQL string in dapper.
You can look at the source for Cofoundry commands for inspiration, although they can be more complex than your typically domain needs to be. UpdateCustomEntityUrlCommandHandler is fairly straight forward.
I'd stress again that Cofoundry is not opinionated on how you do your data access, and isn't intended to provide guidance on building those custom parts of your application.
thanks for the reference, this seems like the case we are after :)