1

I have a Windows Form for creating configs. It has around 50 fields of data, which represent a group of entities, that I need to capture when the user presses the save button. Currently, on the press of the save button I build the group of Entities by creating each entity, extracting the information from the controls and then save them to the database.

I am now working on functionality to import the partly built configs from XML. With the way the save button works I would be replicating almost all of the save code to achieve this.

The only alternative I think of was to pass the values of the controls as parameters to a new class that will contain methods that build and return an entity. However, passing ~15 parameters to each entity creator method does not seem to be a clean solution.

Is there any clean way of disconnecting the save logic from the WinForm that will enable me to reuse the save code?

  • Model View Presenter. Model View Presenter. Model View Presenter. – RubberDuck Jun 29 '16 at 14:58
  • @RubberDuck: if I got MVP correctly, this is helpful if someone wants to exchange one kind of UI against another. However, just by separating the view from the presenter the save logic would probably still be tied to the presenter, which I guess would not be sufficient to solve the OPs problem. – Doc Brown Jun 29 '16 at 18:26
  • @DocBrown you're probably right, but it's a step in the right direction. – RubberDuck Jun 29 '16 at 18:56
1

Start with some building blocks first:

  • make a class MyConfigData, a simple DTO object, no special logic here. It should hold all the configuration data you want to manage

  • implement methods void SetData(MyConfigData config) and MyConfigData GetData() in your form - these two methods should transfer the data from the DTO object into the form, and vice versa.

  • create a class ConfigDbRepo with a method Save(MyConfigData config) and MyConfigData Load(). Put the database load and save logic here.

  • put the code to load and save the config data from or to an XML file in a similar class ConfigXmlRepo. If you like, the two classes can have a common interface IConfigRepo, but that is not mandatory.

What remains is to connect these pieces together. How you will do this depends somewhat on how your application works in general, if your form is modal or non-modal, and how exactly your application controls when to load/save from a db and when to load/save to an XML file. But I hope it is clear that with these tools you can load a config from an arbitrary source (Xml, Db, Form) and save it also to an arbitrary source (Xml, Db, Form), without any avoidable duplicate code.

  • This was extremely helpful. I was able to build outward from these building blocks and I've managed to make a lot of code reusable as a result. – Joe Dawtry Jun 30 '16 at 13:42
1
   > Is there any clean way of disconnecting the save 
   > logic from the WinForm that will enable me to reuse the save code?

Usually this is solved by implementing a Three-tier_architecture

  • Data Object Class with a property of all attributes used in the database and the gui
  • a gui layer that transfers data between Data Object and gui
  • database or repositry layer that transfers between Data Object and database

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.