Closed acrm closed 6 years ago
@acrm Why don't we have classes for each page inside our project instead of having separate applications?
Good question! Honestly, I just haven't considered such variant. It should works and solve all mentioned problems. But there is one requirement that I also want to be met. It is a low coupling between infrustructure and business logic. Let's consider our Middleware is a webserver model and our pages are site's buiseness logic. Webserver shouldn't change if we make some changes in site's webpages, add, or remove some of them. And webpages also shouldn't be changed if we make some internal changes in webserver. So, we do can implement all pages as classes of same project with infrastructure, but it's obligate not to reference webpages classes from the Middleware. We need to figure out some mechanism, that calls corresponding webpage class for request, without knowing in advance which pages exist. Let's do this.
@acrm Then I can imagine some perversion like reading and invoking the code from existing string or text file. Another variant is to have some predefined text files with HTML and certain marks (code-like expressions?) inside that can be parsed and interpreted by our webserver in order to obtain correct HTML with real-time generated data
You anticipate our next step) That's right, let's start from code files, that will be compiled right in runtime, and invoked immediately.
You can start with that example: Runtime compilation
@acrm I used http://www.tugberkugurlu.com/archive/compiling-c-sharp-code-into-memory-and-executing-it-with-roslyn instead of CodeDom (.Net Core dislikes CodeDom - see https://github.com/dotnet/corefx/issues/12180).
What is good in pre-compiled executables?
But what drawbacks we get with this approach?
Any ideas how to overcome these disadvantages, keeping all benefits?