Question
1
Replies
49
Views
Posted: September 11, 2020
Last activity: September 11, 2020
Solved
Best practices on application logic
Hello there,
I have a question from the perspective of the best practices.
I'm building a solution with an use case that requires the use of two different applications.
What is the best way to structure the logic of the two different applications?
- Do I make two subfolders ("Application 1", "Application 2") in the same project as the use case?
- Or do I make two seperate projects and call them "Adapter Application 1", "Adapter Application 2" and isolate all application logic in there?
If the "right" answer is the second option; are there any circumestances thinkable where it's acceptable to place both use case logic and adapter logic in one project?
Thanks in advance.
Our best practice is to use option 2. Separate projects allow you to test your automations apart from the solution. The only time I would ever place multiple unrelated adapters (unrelated meaning that you can run and test one application without the other) within the same project is if I were using a Citrix Context to use Citrix "mixed-mode", as that's the only way to use Contexts (those solutions require a single project). Even then, I would still build my adapters as separate projects and import them into the main project/solution. The reason being is that with a single project, you cannot have multiple developers sharing resources as there's no way to merge those changes together. In addition, creating separate projects allows your adapter projects to focus on the logic for an adapter versus the logic for your solution. An example might be adding a note. You adapter project would have an automation that adds a note and takes in the text of the note to add (or the category to select, etc...). Your solution would have a requirement to add a note with a specific category based on logic and then come up with specific text to add to the note body. Ideally, this logic is done outside of the adapter, so that the "AddNote" automation is wholly reusable.