Base Class architecture
I'm working on building a highly versatile base class that I intend to use in numerous applications and projects, so I'm trying to theorize the best way to build this class (see code attached).
Requirements:
- Quartz is the scheduling mechanism that will be used in the apps (and the base worker should be derived from that structure)
- In the UIs, users will be able to choose workflows (which are tied to specific applications) and be able to choose the source/destination (ie SDK->SQL or SQL->File, etc)
- The rest of configuration (stored in SQL) will be written to file, somewhere, that the apps will pick up through this Quartz worker.
For example:
- A user goes into the UI and selects that they want to pull connection statistics from Server A ("connection statistics" would be tied to a specific class that would inherit from the base, which defines the powershell/sdk/etc to extract or flush records in the correct format)
- The user chooses the server to pull the statistics from.
- The user chooses to write the output to file.
- The user chooses to execute the task now.
Or another example:
- A user goes into the UI and selects that they want to write data to Server B
- The user chooses the server to write data to
- The user chooses SQL as the source to select xx records
- The user chooses to write the output to the server itself (ie via SDK)
3 Replies
My question, is, am I on the right track? This class currently does Source->Destination and Destination->Source (effectively). Should this be broken out? One base class, another to reverse data flow? The intent is that I'd have the application specific classes that determine how data is pulled and formatted, and then I/O (extract/flush) classes for being able to read/write to file, SQL, or SDK
Could you $paste your code so far?
If your code is too long, you can post to https://paste.mod.gg/, save, and copy the link into chat for others to see your shared code!