C#•8mo ago

MVVN w/ Dependency Injection: Best Practice

This question is for those who have personal experience building applications with the use of an MVVN model in combination with Dependency Injection. Dear People o’ Kindness, I have a class that is responsible for providing utility related to serializing, deserializing, writing and reading to files. At the moment, this class is static, accessible from everywhere in the program, and has an “Initialization” method that is called from the program’s Main method. I am considering making this class non-static and then passing it as a transient service to any ViewModel that requests it. Instead of Initializing it in the program’s Main, it would be automatically “initialized” in its constructor every time it is requested. Should I do this, and should the ViewModels be the receiver of these kinds of services? Thanks, Guy on the internet (:

23 Replies

LiteFlick•8mo ago

....

Tesseraction•8mo ago

•O•

Samuel•8mo ago

Is there a reason why you can't make this a Singleton? That way your initialization will only occur once

Insire•8mo ago

this isnt really related to WPF or MVVM. Whether you should be doing this, depends on the advantages you want to gain. so, what are the advantages of making that static class non static and recreating and reinitializing it every time its needed?

Tesseraction•8mo ago

I didn’t think about that. I guess as long as I can have multiple objects request one singletons service, that would be fine It just seems cleaner to me if the class is being used only in the view model layer and is only given access to the objects that request it. That way I avoid any global issues that could happen down the line. It’s just a hunch

JakenVeina•8mo ago

intuitively, singleton seems like the way to go if it's static now, then you've already determined that's not an issue you care about

Tesseraction•8mo ago

The project is only about a week old and I’m taking this opportunity to learn MVVM and DI, so that’s why I’m considering refactoring it to use a different approach. With that in mind, I might just make it a singleton like you suggested Thanks guys (:

JakenVeina•8mo ago

no a separate note, this would be the "recommended" pattern for what you decsribe...

public class MySerializationService
{
    public static MySerializationService Create(...)
    {
        ...

        return new(...);
    }

    private MySerializationService(...)
    {
        ...
    }
}

public class MySerializationService
{
    public static MySerializationService Create(...)
    {
        ...

        return new(...);
    }

    private MySerializationService(...)
    {
        ...
    }
}

I.E. eliminate the possibility entirely that you can neglect to initialize the object of course, you can just combine Create() into the constructor, but separate static methods is a nice pattern if there are multiple ways to do initialization, and it's a necessity if your initialization needs to be async

Tesseraction•8mo ago

you’re recommending making a static class with methods to provide instances of my serialization class? What would be the advantage of this vs using dependency injection, which I could use to hand off the service to specifically the ViewModel layer?

JakenVeina•8mo ago

no the above class is not static and does not preclude use of DI/IoC

Tesseraction•8mo ago

Oh wait yeah I just noticed that I just learned that in an MVVM architecture, the view model layer should not be responsible for saving and loading data. The model layer should do that. So should I make the view model layer take that service as a dependency and then pass it on for the model layer through model object constructors, or should I be passing the service as dependencies directly to the model somehow?

JakenVeina•8mo ago

models generally don't have any dependencies they're just plain data objects pure state, no logic a serialization service would very much be a candidate for being injected into the VM layer, yes and it would OPERATE upon the model layer or, one might argue, the Data Access layer

Tesseraction•8mo ago

So the Model layer would mostly just be some structs and classes that hold data and provide some super basic utility methods for working with that data, and the view model layer is responsible for all of the logic pertaining to that data, including saving and loading data, interacting with APIs, etc? Of course this is all assuming that the view model layer is utilizing services to help with these things

JakenVeina•8mo ago

yup

Tesseraction•8mo ago

Wow Mind blown

JakenVeina•8mo ago

and like I said, you'll often consider "Data Access" as a layer as well as in "the layer for persistent data storage and retrieval" I.E. a database, in many cases or maybe just a cache for one or more JSON files

Tesseraction•8mo ago

So often coming in the form of some sort of API passed as a service?

JakenVeina•8mo ago

maybe

Tesseraction•8mo ago

I think that sounds like the best option for me based on what we discussed My application has “files” (really folders with some xml data in it). So it sounds like it might be a good idea to have all of the data structures inside of the model, and then provide a service that is just responsible for saving and loading data from “files” and creating new ones”. Then the view model layer could take that service as a dependency and use it to manage “files” and create model objects out of it using the data structures provided in the model layer Do you think that’s a fairly sound plan?

Insire•8mo ago

fun fact, MVVM does not concern itself with layers or data access models are just a representation of the data your app sends/receives some ppl also put the business logic there another fun fact: there is atleast 2 flavors of MVVM view first MVVM and viewmodel first MVVM

Tesseraction•8mo ago

I guess that explains why I’ve heard some conflicting things regarding the role of the view model. I’m going to have to research those 2 flavors so I can decide exactly what route to take here. Thanks for all your help. It was very constructive

Insire•8mo ago

thats just the 2 main ones, you can find loads of blog posts, where ppl halfass MVVM or claim to do MVVM without actually understanding the pattern and breaking it left, right and center the thing where you put businesslogic into the models is probably the third variant, but i havent seen actual code of someone doing that yet, so im calling that a fairytale still

Tesseraction•8mo ago

I guess some people have different variants of the meaning “business logic”. Some people might just think that business logic includes things like calculating certain values from model data, and store methods for that within the model. I guess because of the need for separation of concerns, people generally bring most of the other logic into services and then it’s just a matter of deciding which “layer” is going to use those services. Anyways, I’m gonna go ahead and close this thread Once again, thanks for the help

Gaming

Programming

MVVN w/ Dependency Injection: Best Practice