I'm trying to design an application, something quite generic over a .NET C# Stack.

It's supposed to be an desktop application intended to control industrial equipment and to perform measurements and testing, however it's planned to be able to switch later on different UIs dealing with different

I'm trying to have a pretty generic approach:

  • UI Agnostic: Webpages / Winforms / WPF / GTK# / Whathever, etc. using naked objects in order to avoid the hassles of a lot boiler-plate UI code.
  • DB Agnostic for storing Data (ADO.NET & EF can deal with that)
  • Remote Control and Monitoring (that's really tricky but I guess with WCF I should manage to have a remote access with service running on the remote client)
  • User Management
  • External Industrial Resources (devices)
  • Logging and bug reporting
  • Reporting and data exportation
  • Licensing

The business layer of the application is split into three main parts and leveraging the other parts described above:

  • Edition: define a set of tests (flowchart) with conditions (user interactions, results fetching during the tests) using the industrial resources available
  • Operation: perform the tests defined above with user interaction (if any defined in during the previous step)
  • Analysis: deal with the data (DB) that have been recorded accordingly to the test definition given in the edition part and provide some statistical computations: data mining features (clustering, anomaly detection, etc.) and reporting feature (that can also be defined to be generated automatically at different moment of the operation).

My problem is that I would like to have a modular approach and I'm wondering whether this is really desirable in my case. The approach is sound but at the same time it seems like providing a lot of issues.

Theoretically, it means you can test your modules independently from each others but actually in most cases even though you can mock the inputs / outputs required for the tests, the reality is still that it requires other dependencies to make it run and this is for me the real bottom line in this approach. The fact that you can load and unload some are for me only applicable in a couple of situations but not that many.

For instance, the User Management is using the Database Module which probably also going to use another enciphering module and so on and on and on.

Later on the remote control and monitoring would also eventually use that so... my point is that it seems pretty hard to have modules fully independent here.

The plugin / modular approach would work like a charm for external industrial resources where those devices would have to implement a certain interface to be compatible with the system.

But about the rest I'm really suspicious whether it worth the hassle of using MEF or any other plugin / extension framework.

What do you think? Is the modular approach really applicable to everything in my case? Or just a couple of features can take advantage of it.

  • 2
    What is your specific, software design-related question? Sep 30, 2015 at 3:32
  • @RobertHarvey "What do you think? Is the modular approach really applicable to everything in my case? Or just a couple of features can take advantage of it." is not specific enough? (don't get me wrong, I'm not sarcastic here). Sep 30, 2015 at 3:50
  • 4
    I don't see how that question is answerable without a detailed analysis of your specific system and its functional and non-functional requirements. Any answer would probably have to take the intersection of those requirements and MEF's features, and then make a subjective determination based on the resulting mapping. All in all, it's probably a bit too much for a Q&A. Sep 30, 2015 at 4:24
  • @RobertHarvey alright then, I'm going to edit the post to make it more specific. Sep 30, 2015 at 4:28

1 Answer 1


We are working on same Architecture with different approaches. Currently we working with plug-in approaches with EF because when we talking about Licensing and Reporting that’s should be customer based need or requirement, For example currently some customer need some basic feature of application that’s based on licensing and some require some more feature and custom base report so every time you don’t need to build whole project and update or upload on server . Plug in based Architect is good when some existing customer wants some new feature so you can develop and upload and plug so there is no need to set for every customer I hope this will help you. Thanks

  • This is sound answer. However, I'm actually a bit more concerned by the interdependency among the plugins that seem really a pain to maintain over the time. Sep 30, 2015 at 5:43
  • @EhouarnPerret - The Application Architecture its not depend over plugin right so plugin just add more feature and every plugin may not allow to change or alter in main architechyure. This way not create any problme. Sep 30, 2015 at 5:50
  • I see so according to you it's better to keep the plugin way only when it does bring real benefits and not build the all application based plugins, the rest is still remains on a core block without plugins support area. I've read another point of view here (icsharpcode.net/TechNotes/ProgramArchitecture.pdf), where the core is quite small and the team who built SharpDevelop has decided to go with full add-in almost everywhere. There is no one size fits all strategy applicable here, but I thought that there was some alternatives to avoid the common mess of having plugins everywhere. Sep 30, 2015 at 6:05
  • As this Doc I suggest to you once see nopCommerce project which is same as this doc every thing in this project. its use AUTOFAC depends technique , Resources , UI, Utilities and many more. Sep 30, 2015 at 6:13

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