Can the API and the NSB endpoint projects be merged into a single project?
Closed this issue · 6 comments
While I agree that this is a perfectly valid approach, providing some interesting examples on how to split up a service into multiple deployment units for decoupling, better availability and so, I'm not sure I see the value for the workshop exercises.
Especially when not using the special VS plugin for the startup projects, the dedicated host processes feel very noisy and cumbersome. The huge amount of open console windows is hard to oversee and it takes some time to find the right console window in case I wan't to look at the log output.
Merging the API and the NSB related code into a single project would make the project structure easier to view, the solution easier to setup and more convenient to run. The code can still be highly decoupled, so besides from a deployment perspective, not that much really changes?
thoughts @Particular/workshop-maintainers ?
I would not merge them into a single project. They have very clear and distinct responsibilities. Perhaps they could both be hosted in a single process, but that would involve adding to the total number of projects rather then subtracting.
They have very clear and distinct responsibilities.
agreed, however I don't think this makes dedicated projects and hosts necessary. highly decoupled components can still easily reside inside the same project. I don't see any special benefit of having them in dedicated project files?
highly decoupled components can still easily reside inside the same project
That's true, but then you'd have very low cohesion inside that project between the two areas of responsibility. I prefer to embrace, and enforce that, through project separation, to lower the chance of someone doing something bad.
but then you'd have very low cohesion inside that project between the two areas of responsibility.
I don't see a problem with that tbh. As said, I don't argue that it's a bad idea in general, I agree that it's a valid approach but I still think for the sake of the workshop, it creates an annoying amount of noise and more manual configuration (startup projects) to prevent a problem which won't be an issue in the scope of the workshop at all.
This reminds me of why I started a series of blogposts on WCF, back in the days. I saw someone else post a "Simplest WCF Example" blogpost in which he hosted both the sender as the receiver by creating new processes, etc. It was so &*$()## awful that I decided I could do better.
No offense, but isn't there a better solution? Like hiding the console windows that aren't interesting via some interop code or whatever? Or open up various webpages so everyone understands the difference between the API hosted projects and the console endpoints?
Oh, wait a minute... 😇
We had a discussion and decided to leave the projects as-is. We will look into other options to make the flood of console windows more manageable, e.g. colouring per service, minimising some console windows on start up.