It seems as though Marten is geared toward ASP.NET, am I correct in that assessment? I'd like to consider adapting the core basics into a WPF application. Fundamentally thinking that IServiceCollection swaps for Application if not also Application.Resources, for starters, and on from there. Could not add a WPF tag, but whatever.
#Adapting Marten into WPF
fervent beacon
I started toward this PR endeavor, forked, etc. May have couple of fundamental questions about the necessity of certain areas, analogs to IServiceCollection thingies, scopes, life cycles, etc. I have a fundamental grasp of those things based on SL/DI principles, but in terms of mapping those areas to a WPF, Application, ResourceDictionary, along these lines. The last thing I want to do is get opinionated about any DI containers, or maybe does it even make sense to introduce an IServiceCollection into an Application, along these lines.
Will leave it there for the moment, looking forward to constructive feedback.
fervent beacon
Will also investigate the perhaps obvious question, does it make sense to add an IServiceCollection to an Application. Then perhaps could more simply stand up Marten. I do not exactly want to add a host to the application, that is unnecessary, and I'm not sure 1. what problem that solves, or 2. how I would gain access to the necessary services, outside of perhaps MVVM messages polling for such, which is quite probably possible, as well, but trying to keep the access simple.
fervent beacon
trim berry
I don't know if you've seen, but you can scaffold marten with DocumentStore.For, and completely skip the container.
There's some features and conveniences unavailable this way but it's still usable.
Microsoft also provides a full guide of using MVVM + DI together as part of the community toolkit https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/ioc
fervent beacon
Ah okay, did not come across that yet. Thanks so much.
I am using the community toolkit, of course, in so many ways. But I do not mind connecting the DI container. Seems simple easy enough to do, barring any IHost gotcha caveats I should know about.
ObservableObject, IRecipient<T> messaging. Works pretty good, and only in a couple of places do I need to remember to join back to the the Window main event loop.
My main focus at the moment, now that I have my models, views, view models more or less sorted out, is arranging the data, persistence, serialization layers.
I could run the simple poco style entity or nhibernate approach, but I kinda like the idea of document storage, in general, and possibly even of the marten event sourcing.
trim berry
Is the intention that the WPF app and postgres would run on the same system?
fervent beacon
At least initially.
I do not know how good postgres is at being portable; along which lines NoSQL SQLite was one possibility, but the ecosystem is pretty sparse for proper JSON document storage there as well.
So far I think this does the trick. Of course connection strings, options, etc, those gaps need filling. UseServiceCollection (returns Application) mine; as is GetResource<R>(...) obviously returning IServiceCollection.
protected override void OnStartup(StartupEventArgs e)
{
this.UseServiceCollection()
.GetResource<IServiceCollection>()
.AddMarten();
base.OnStartup(e);
}
After that of course training Marten what my models need for storage.
fervent beacon
Easy peasy one connection string later, connected to the database, actually was created, and presumably connected. Albeit no model training yet. But that's a good first next step. 👍