Base solution for your next web application
Starts in:
01 DAYS
01 HRS
01 MIN
01 SEC
Open Closed

Best Practice for Treating ABPZero as Module? #5066


User avatar
0
jcompagnon created

Hello,

First off, I'd like to say, great job on the framework. I've learned a lot from playing around with ABP in the past year, and the polish on ABPZero is terrific. Being a newer dev, and coming from the limitations of developing extensions tailored to a particular CMS, I had (and have) a lot to learn about robust design, and ABPZero/Boilerplate and these forums have really helped me to understand the SOLID principles and currently available tools.

On that note, I'm looking for advice on how I could approach a design problem I'm running into, and any direction to how I might approach it, or where I should look to find more info.

The company for which I work is looking to rebuild our "Core"/starter template, this time based on ABPZero. Our main source of projects is creating web apps for research "Studies" for researchers within our company, which are generally non-permanent, and all hosted on our facility's servers. These Studies typically have a lot in common, but each one has customizations related to the type of study, and particular research being done (such as unique forms, different relationships of users to the workflows, etc). Because we frequently have several projects live at any given time (currently, ~20), we want to be able to easily push updates from our Core, when we make updates to make use of newer ABP versions, or bug fixes to the common Core.

A solution I was hoping to try was to have one central repo for the Core, being the ABPZero template & our standard tools (using the ABP Update suggestion posted on github <a class="postlink" href="https://github.com/aspnetzero/aspnet-zero/issues/96#issuecomment-268093697">https://github.com/aspnetzero/aspnet-ze ... -268093697</a> ), package each core template project (Mvc, App, EF, etc) as a separate nupkg (on a private nuget feed!), and creating small modules per-Study that would load up the entire application, adding whatever customization a particular Study requires.

Currently, that means I'm embedding the resources & views of the MVC project, and loading the entire MVC app into my smaller web module. However, I'm not sure if this approach is 'best-practice', or even 'okay-practice', and was wondering if instead I should be basing new Studies on the MVC project, and handling updates made to the MVC Core manually for each project. This could be quite time-consuming across the projects we have, though, so I worry about the maintenance required.

Has anyone run into this issue and have some advice or warnings about approaching it this way, or suggestions as to how it could be approached differently? I know it's a bit out-of-scope for support, but any advice would be greatly appreciated!

Thanks!


2 Answer(s)
  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @JCompagnon,

    I think your approach is really good. I think you don't want other modules to change your base modules (Core, EF, MVC etc...). If you can bundle your projects like seperate private nuget packages and bundle View files, Js files and css files, the projects using those nuget packages even can override base views.

    You can take a look at <a class="postlink" href="https://docs.microsoft.com/en-us/aspnet/core/mvc/advanced/app-parts?view=aspnetcore-2.0">https://docs.microsoft.com/en-us/aspnet ... etcore-2.0</a>.

    Since we haven't tried this approach in real world, you can take a look at other options as well :).

  • User Avatar
    0
    jcompagnon created

    Hi Ismail,

    Perfect, that sounds like what I was looking for ; I'll take a look at those application parts, and run with it for now.

    Thank you once again for the feedback & the resources!