-3

I am working in C# (Windows Forms app) and I am making a 3-layered application. The problem I have stumbled upon is the communication between the UI and the BLL. The application copies/manipulates/stores/gets etc. data from different data sources and here is that problem that we anticipate that more data sources will be added over time.

I see that I have two options with the interface from the BLL:

  1. I add the copy method signature for each possible way to copy data, like: CopyFromSource1ToDestination2(), CopyFromSource2ToDestination1(), and so forth - I don't like this as it will expand the interface over time.

  2. Have a copy method in the interface: Copy(object source, object destination). But then I don't know how to tell the UI what are legal objects for source and destination (preferably with the use of intellisense).

My question looks a lot like this one: "Design Pattern for data import of various source types and to various destination types" - But I am not able to use the MEF as suggested as far as I can tell.

Example code would be like (from the BLL interface):

public interface IPlmBusiness
{ 
    bool GetDbDataToActiveExcelSheet(string fullQuery);
}

I see two major issues on this one: 1. For every data point (DB, excel, files, REST client - what ever) I have to create a long set of methods to handle the commands from the UI. 2. In this example I have to know the query on the UI side, I would like that to be in a lookup table of some sort.

  • 4
    please add example code that you have. Sounds like generics will solve your problem maybe – Ewan Feb 11 at 11:52
  • As Ewan says, generics likely would solve your problem, eg having Copy<TSource, TDestination>(TSource source, TDestination destination), but it's hard to be sure from your example code. – David Arno Feb 11 at 12:14
  • You may want to look into the MVP UI pattern (en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter). That's the version of MVC that is meant to work for WinForms apps. Bottom line, some interface separation can help you make some modular code. – Berin Loritsch Feb 11 at 13:56
  • If you need to add more data sources later, I assume that is because you are adding more functionality later. If you are adding more functionality later, then you will have to add more code too. Can't really escape that. I understand the desire to make things generic, but since the UI won't know what the legal members are for a generically declared object, a generic solution would be incomplete, and possibly counterproductive. Sometimes you gotta write code. – John Wu Feb 12 at 1:38

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.