Timeline for SQL Database design for reusable components and classes
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 26, 2023 at 5:02 | comment | added | aterbo | As far as maintain, I was envisioning something like a versioned NuGet package that would contain all of my Comment classes and some simple UI components. I could then add in that package to all of my apps. If I need to update the package to, say, add additional parameters, I can then release a new version of the package and choose which apps I want to update and when (or if). No need for anything like automatically updating all implementations. We are very hands-on with our app, and minor tweaks and redeploys aren't a problem. But, I may be going down the wrong path with that thought.. | |
| Apr 26, 2023 at 4:57 | comment | added | Flater | I got close to a final answer but then you said "easily maintain". Are you expecting the ability to update your core logic and have this apply to existing instances automatically, or are you happy with the implementation being "locked in" at the time of first implementation? | |
| Apr 26, 2023 at 4:55 | comment | added | aterbo | Templating, for sure. No need for runtime reusability. If I could get to a versioned package to share, that would be ideal (I think). I just need to be able to easily maintain a dozen or so applications. These apps were all originally developed as fully-custom programs, but so much of the functionality is similar, I am trying to move to semi-custom for the sake of ease of maintenance (and sanity) | |
| Apr 26, 2023 at 4:52 | comment | added | Flater | The next question, based on your comment, is whether you need runtime reusability or if a simple template would suffice. The issue here seems to be the effort of writing it, not necessarily the fact that these comments have different lifecycles once they've been implemented. Correct me if I'm wrong. | |
| Apr 26, 2023 at 4:45 | comment | added | aterbo | @Flater hm, that's an interesting question and I guess I'm not 100% sure. I think (a) is more accurate. My primary goal is to stop having to rewrite things like the CRUD operations and UI components for the comments, and I want to be able to say "Here's an object, add in all the comment input and display widgets to add comments to this object" with the least amount of boilerplate possible. I want to stop building almost identical grids. Although, that said, I do need some level of control over things like which users can access the add comment button. I'm not sure if that really answers you.. | |
| Apr 26, 2023 at 4:37 | comment | added | Flater | "What I would like to do would be to reuse the CORE Comment data as a class with associated interfaces ...." There are two main paths here. (a) Your code will only be able to rely on the base comment logic and will not account for any inherited details such as the FK: or (b) you will have to write a complex inheritance hierarchy involving generics and inherited overrides. Both work, but they're very different as to behavior and complexity - what do you want? | |
| S Apr 26, 2023 at 3:39 | review | First questions | |||
| Apr 26, 2023 at 6:15 | |||||
| S Apr 26, 2023 at 3:39 | history | asked | aterbo | CC BY-SA 4.0 |