Question about Avalonia structure, addon capability and generall seperation of projects
I want to make a small Desktop app using Avalonia, my current structure is:
MyApp.sln contains:
- MyApp.UI -> for UI stuff only
- MyApp.Core -> for logic
- MyApp.Data -> for data fetching and handling
- MyApp.Test -> for tests of all kinds
im pretty happy with this structure but I have a process in the app that allows for data exports and I currently only support JSON and PostgreSQL, but since i might want to extend this later i thought why not open it
so my approach would be to have a MyApp.SDK (contains the interfaces) which is a seperate project and repository that gets published as a DLL (and NuGet etc etc) and using this I could create MyApp.Exports.SQLite or something, I would have MyApp.Core reference the SDK and have some sort of "addon loader" function that can load MyApp.Exports.SQLite
Is this the correct approach for allowing addons / plugins to be written for my application? I have never done such thing before
8 Replies
4 projects for a small app is crazy
as for the addons yeah, you will have some kind of reflection based loader that can load components from user defined assemblies at runtime
i wouldn't break the app itself into more than one project until you have a good reason to
I know it might be over engineered but I want to learn multi module architecture stuff so I thought it might be a good fit since I can't think of another project than a desktop app that could utilize it :SCfeet:
you don't need that many projects to make it modular or support plugins
at minimum the plugins can reference the app dll/exe itself
How would that look like :LIT_he:
not sure what you mean, the same way you typically reference another assembly
if you want to break the plugin API into a different project that makes sense, but the rest looks overkill to me
do you mean its overkill that I have UI, Core, Data and Test seperated or do you mean its overkill because id have a seperate project for each plugin :LIT_he:
the list you provided is overkill, imo
i'd start with a project for the app and a project for tests, and only break it down further if you have a good reason to
plugins have to be their own projects because they're developed and compiled separately from the app
At most three for a small project, .Test for testing, .SDK if you want to expose interfaces for extensions, and everything else in the same main project.
For your own extensions/plugins, they can live the main project. I guess you want to follow the convention of big products (VS, Office, etc.) but that's not really going to work very well if no one actually writes extensions for your product.