2

I am making a WinForms application using Code First and Ef Core. The problem is the amount of dependencies I have to deal with. This is how my class currently looks.

enter image description here

Each of my services needs a db context as well, so you can imagine how ugly it would look.

enter image description here

I am trying to imitate the ASP.NET Core MVC architecture inside my app.

Models(db models)

Views(in my case just Forms)

Controllers(they get a form and populate it with data using the services, after that they return the form)

What is the best way to deal with the dependencies in my WinForms app, knowing that In the future I will have more services and more classes that need them?

Nikola Develops
  • 151
  • 3
  • 12
  • 1
    Why are you trying to imitate MVC in a WinForms app rather than use WPF with the MVVM pattern? Regardless, a major issue I see here is your Controller depends on your view, that dependency should be the other way around. Once you do that you could split controllers like this one then have multiple controllers to support a single form – HasaniH Apr 10 '22 at 14:56
  • 1
    Take a look at: [How to avoid Dependency Injection constructor madness?](https://stackoverflow.com/q/2420193/3110834) - You cannot expect one correct answer for this question as each answer may be correct in a context. Make sure that your class in not taking too much responsibilities. Also see if you can use a (few) Façade(s) to reduce the number of dependencies. – Reza Aghaei Apr 10 '22 at 18:44
  • Thank you both for taking the time to respond to me. I will try using MVVM and creating Fascade classes. One more question - should each service deal with a single entity in the database? In my case I have tables that are with a relationship many to many and I have created services for them as well, should I put all related services in one big service class instead? (for example PublishedWorkService,PublishedWorkCharacterService,PublishedWorkGenreService ... to be in a single service class because they are all related to PublishedWork) or the way I've separated them is better? – Nikola Develops Apr 11 '22 at 14:43
  • 1
    @NikolaDevelops the lifecycle of those entities are different and independent, then it's better to use different service classes, but if they cannot exist independently, then you may want to merge some of them. For example, imagine an Order and an OrderItems table where each order may have many order items and each order item belong to a single order. An order can exists independently from order items, but an order item cannot live independently, to instantiate it, you just need to add it to an order, or to edit it, you need to open an order ... – Reza Aghaei Apr 11 '22 at 21:35
  • 1
    ... in above example, it's better to create a service for Order which takes care of order. You can create an OrderDetail service, but it doesn't make much sense because you don't want to have an AddOrderDetail method there, because order details will be inserted as part of AddOrder or EditOrder. – Reza Aghaei Apr 11 '22 at 21:41

0 Answers0