What architecture/guidelines should be considered to write reusable module of project?

Question

Introduction

I am working on MyProject which is windows (desktop) application being developed in C#.NET and DotNet Framework 4 in WPF. Project is layered as DataAccessLayer (DAL) --> BusinessLogicLayer (BLL) --> ApplicationLayer (UI).

This project has a module called MyModule which needs to be reused in other multiple projects with minimum changes and possibility of bugs.

All projects will be using same development environment as that of MyProject. But, DAL will be entirely different; it will NOT be reused. Module will have no control over it. Module will have BLL which will be reused by all calling applications. Also UI of module will be modified by calling application. XAML code will not be a part of distribution; it will be newly written by calling application.

Distribution

This module will be provided to other projects in form of compiled DLLs. Calling application will write its own XAML code and will bind ViewModels exposed by module. Ideally that should work but little extra may be needed.

Additionally, BLL will be distributed which will be reused as is.

More about MyModule: -

This module consists of one main UI window. From this main window, multiple sub windows will be launched. Module raises events those needs to be handled by calling application. Module needs inputs those needs to be provided by calling application.

Example

Microsoft decides (I am sure they must be doing it now) to reuse "Options" window (File-Options) across all MS Office projects. But each project can decide GUI of window, where the settings should be saved, how (XML/INI file etc.) the settings should be saved etc.

My Plan

I am planning to expose one ViewModel per window. I will also expose events/enums/structs as necessary. To accept data (as DAL will be entirely different), I will expose DTO classes which calling application will inject in module.

Problem

I have created reusable modules earlier many times. All those modules were DLLs without GUI. There was no role of binding UI elements and events with calling application, allowing caller to design its own UI etc. My key problem here is how to achieve this? What guidelines should be followed? What architecture should be used? How to expose an interface in a DLL that is bindable to a WPF project?

You may suggest corrections in my plan or discard my plan all away and suggest your new plan.

Answer 1

The architecture I mentioned in question looks good to me.

For other details, I choose to implement MVVM with Portable Assembly.

Following references helped me:

https://msdn.microsoft.com/en-us/library/hh563947(v=vs.110).aspx

https://blogs.msdn.microsoft.com/kaevans/2014/04/09/using-portable-class-libraries-to-reuse-models-and-viewmodels/

https://blogs.msdn.microsoft.com/nathannesbit/2014/08/20/reusing-viewmodels-in-a-universal-app-part-1/

Answer 2

One way you can achieve it is by

1. Creating a web service that basically serves all the requests coming to the application even the ones that are related to the client application User Interface. and your application specific request that you intent to execute using your UserInterface.
2. Create user controls with UserInterface that uses your service and share this user controls with the clients to enable them to use your user interface and integrate it in their application.

I think this should work for you..