1

Topic: API and puff architecture

Let's admit that there is a certain architecture, in which five layers: 1) level of operation with codings of the text and file formats 2) level of text operations of the editor of texts (to add an indent for group of lines) 3) level of elements and attributes of a xml-format 4) object level of the abstract project msbuild 5) object level C# programs in a format.csproj In each layer are the API, the dial-ups of operations, the data structures and constants. If it would be desirable to have complete control over everything, but thus not to give access to lower layers on a straight line everyone higher appears is more volume previous (as includes all that already is more low, but in own way). The idea is that - to allow to use API all levels, and not just immediately underlaying. That by operation with lower layer elements it was possible to do something comprehended with top level the context should be visible, that is inter-element couplings of object models of different levels should be double-side. Further the thought does not go.

2

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: AS> Further the thought does not go. To read FDG (it is accessible in safari books, the trial for 10 days should suffice). A mandatory piece for the person who wants to be engaged in designing API under.net (and not only under.net).) + architecture guidelines book. In last you the general approach interests, is painted in Chapter 5: Layered Application Guidelines, in the first - ability to think correctly and to catch errors in reasonings before they affect design API. At you a problem not in actually sharing on layers, and that you try to make it, passing all previous stages, from case study and before clearing up key . Well and , it turns out that "everyone higher appears is more volume previous (as includes all that already is more low, but in own way)".

3

Re: API and puff architecture

S> At you a problem I viewed (not explicitly read on storage, but all the same) advised, but did not like. The first offered book is good in corporate political wars when it is necessary to knock down authority - we do so because so it is told in FDG. But does not light, with clearness does not fill. Probably I need to read in addition something another. S> you try to make it, passing all previous stages, from case study and before clearing up key . Stages are only in the second, but the emphasis on "responsibility" there is not present. You such read something about "Key Responsibilities" that very much it was pleasant to you, and I did not read.

4

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: S>> At you problem AS> I viewed (not explicitly read on storage, but all the same) advised, but did not like. Aha, if to glance over, as the normal reference manual looks. There all value - not in actually in rules, and in the approach to design API and in explanations. As companions authors think that for them it is important in design API that is not present. To inspire it and should not, but from standard problems of type " __ how we represent as it will be used" treats not bad AS> Stages is only in the second, but the emphasis on "responsibility" there is not present. AS> you such read something about "Key Responsibilities" that very much it was pleasant to you, and I did not read. , it already from experience. It be no point to divide the code into layers until you are not defined with  for each of layers. A classical simple example - operation with XML. It is enough For the majority of users XDocument. Load ("SomeFile"), but all remaining scenarios (up to frank perversions of type of substitution of a name of the coding) are fulfilled through overloads of the same method. As a result on the one hand - intuitive enough code and any  type abstractPatternFacadeSingletonFactory (similar in  does not meet at all, behind it is to ). With another - under a cowl there the present puff pie - reading from a flow, reading of a text flow, tokenization, analysis xml,  (aha very few people knows, but it is) both  and . With the third - the same infrastructure (XmlReader) __ changes  at least in three  on operation with XML (XmlDocument, XDocument, DataCOntractSerializer), and in last - also extends  classes (XmlDictionaryReader and successors). Also works without special changes in public api since the first . 15 years later, aha. Here it I name design of the healthy person. If to ponder - suggests. Especially if to consider that the formal layers here are not present (we tell, a stack xmlReader and a stack xmlWriter with each other are connected unless the general style), the code perfectly works at usage of a functional from different layers and thus usage of the "high-level" code remains quite convenient. Being returned to a subject - the successful design not instinctively turns out. And not as result of attempts to make  (is faster on the contrary, any successful did not see). And as the result "is found the main scenarios of usage, we think how to make public api with minimum WTF moments, we do". The similar approach works not only with specific types, but also with an infrastructure as a whole. Only the amount of scenarios of usage quits noticeably more. Therefore as a rule at first  collect examples of that functional which needs to be implemented, and then scatter responsibility on layers, using a simple principle "knows nothing about". Well, i.e. Stream it is perfectly compiled and works without StreamReader, StreamReader knows about existence Stream, but does not guess about XmlReader and  and . It turns out that each of layers by default uses public API the previous layer __ each layer allows to twist if needed logic of underlaying layers, for example, transferring correctly tuned object. And for design of multilayer API it is necessary * to be able  public API each of layers. * to manage to space apart responsibility so that each of layers not was  is exceptional under needs of the following. Actually all

5

Re: API and puff architecture

Hello, Sinix, you wrote: S> Here it I name design of the healthy person. If to ponder - suggests. Especially if to consider that the formal layers here are not present (we tell, a stack xmlReader and a stack xmlWriter with each other are connected unless the general style), the code perfectly works at usage of a functional from different layers and thus usage of the "high-level" code remains quite convenient. S> Being returned to a subject - the successful design not instinctively turns out. And not as result of attempts to make  (is faster on the contrary, any successful did not see). And as result "we find the main scenarios of usage, we think how to make public api with minimum WTF moments, we do". And whether here rather early to think about public api before creation of the architecture? In my opinion, API then successfully turn out, when are dictated by architecture, rather the reverse. I.e. we build the house, then we cut windows, instead of under . Windows we build the house. Into the account fdg I would argue, since It is more interesting that authors, for from the first  api for 15 years read it really abruptly. It is thought to me with mathematics they were on friendly terms. The book of Stepanova "Elements of programming" is very interesting from this point of view. It quitted later, but is extremely curious and useful for at design something (architecture, api) advises to look at mathematics: the architecture should be similar to creation of proofs in the mathematician, only in the opposite direction. I.e. there is a kernel of architecture (axiom), further forms . A functional (theorems, lemmas). The theorem 1 . In the theorem 2 etc.

6

Re: API and puff architecture

Hello, Sharov, you wrote: S> And whether here rather early to think about public api before creation of the architecture? In my opinion, API then successfully turn out, when are dictated by architecture, rather the reverse. As practice - not early shows if to speak about an infrastructure to which usage scenarios are obvious. Here important presence formalized public api, instead of its quality since we at the earliest stage receive: 1. A dial-up of key scenarios for . 2. The code with examples of usage of these scenarios, it - ready integration tests 3. Possibility to check up architecture on adequacy to requirements. I.e. this stage public API plays a role specifications/requirements with which registration the architecture is under construction and the real code is written. As a result we have adequate idea about the project as a whole literally since zero day. In your analogy I.e. we build the house, then we cut windows, instead of under . Windows we build the house. We do  which registers illuminance level, cooling and that there still on  and in the course of actually designing of the house permanently we check that we in these requirements are laid down. In general, speech about the subsidiary tool, instead of about changeover actually to designing. upd , I even made about it a stipulation in the previous post. All  is shorter. The similar approach works not only with specific types, but also with an infrastructure as a whole. Only the amount of scenarios of usage quits noticeably more. Therefore as a rule at first  collect examples of that functional which needs to be implemented, and then scatter responsibility on layers, using a simple principle "knows nothing about". Well, i.e. Stream it is perfectly compiled and works without StreamReader, StreamReader knows about existence Stream, but does not guess about XmlReader and  and . Just on this idea about constant check by practice aka Framework Design Principle Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios. All FDG also is constructed S> Into the account fdg I argued, since it is more interesting that authors, for from the first  api for 15 years read it really abruptly. It is thought to me with mathematics they were on friendly terms. The book of Stepanova "Elements of programming" is very interesting from this point of view. Well it is unconditional yes. A problem what even FDG units master. Therefore at first to creep, then to fly

7

Re: API and puff architecture

Hello, Sinix, you wrote: S>> Into the account fdg I would argue, since it is more interesting that authors, for from the first  api for 15 years read it really abruptly. It is thought to me with mathematics they were on friendly terms. The book of Stepanova "Elements of programming" is very interesting from this point of view. S> Well it is unconditional yes. A problem what even FDG units master. Therefore at first to creep, then to fly Everything that you write certainly truly with reference to creation , i.e. a dial-up of certain public libraries. Unconditionally there it is necessary to dance from public api, but here, let us assume, the HARDWARE writes especially utilitarian application for the company or user group. I.e. about any public libraries of speech does not go, an end-product. What for to it to read fdg? Yes for the general development, yes there there are good ideas and remarks, but this book hardly useful to the decision will be specific a task in view. Stepans that with its approach just and about will "creep", and fdg already to "fly". : And nevertheless to say that the guy from a msec here it is direct good fellows-good fellows too not so validly. Children not out of the blue and from zero invented all, and looked back (spied) on the world java.

8

Re: API and puff architecture

Hello, Sharov, you wrote: S> What for to it to read fdg? Well a pancake, it is obvious. Any software is not a homogeneous mash from methods and types, inside in the same way there is a sharing on subsystems-layers-components-helpery. Not, in a small software which is developed by pair-triple developers still it is possible to be lazy and dissolve a brothel. And in averages and especially in large-scale projects any component which your command does not own, you can use only through it API. Getting into interiors directly you inevitably spoil life all - from actually developers who cannot repair now an error, without breaking your code and to other commands, whose scenarios easily could break from your changes. Well and further there are only two variants. Or internal API it is written from , or we learn FDG. It is checked up repeatedly, and a difficult method. In one of projects for a system part and a biz-code two commands answered, and in between to adjust dialogue plainly attended nobody. As a result in a year-one and a half of 90 % system API it has been hidden under the helpers developed by the second command. Because all basically  was correct, but there would be no scenario (I seriously, from requests and before creation of business entities) which would not demand a minimum of two-three calls of methods. Not, as a result it turned out even not bad, but the amount of the lines humouring an infrastructure is primary there was time in 5 more than actually business logics. Here such here high-level assembler S> : And nevertheless to say that the guy from a msec here it is direct good fellows-good fellows too not so validly. Children not out of the blue and from zero invented all, and looked back (spied) on the world java. Well, it agree absolutely. One nuance:  is just an excellent example "just the same, only without FDG". Seriously,  which for a part  reading type xml demands knee-bends in the spirit of DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance (); DocumentBuilder dBuilder = dbFactory.newDocumentBuilder (); Document doc = dBuilder.parse (file); and generally it is better to replace a remaining part with indirect libraries (we will not point a finger, but it was Runtime.exec (). jproc, once again thanks). In any way you will not name design peak About transfer Document at line - let's not be. doc.toString () - it is not enough . P.S. Very much-very I suspect that at a command  from this the project behind shoulders was in the core

9

Re: API and puff architecture

Hello, Sinix, you wrote: S>> : And nevertheless to say that the guy from a msec here it is direct good fellows-good fellows too not so validly. Children not out of the blue and from zero invented all, and looked back (spied) on the world java. S> Well, it agree absolutely. One nuance:  is just an excellent example "just the same, only without FDG". Seriously,  which for a part  reading type xml demands knee-bends in the spirit of S> S> DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance (); S> DocumentBuilder dBuilder = dbFactory.newDocumentBuilder (); S> Document doc = dBuilder.parse (file); S> fdg then was not, but here gof already started to create. And in the code above (yes apparently and in all jdk) their influence is felt. And to look at the wrong decision too happens it is extremely useful. As it is not necessary to do almost a business floor.

10

Re: API and puff architecture

So that I carried out from this subject: 1) architecture it difficult-difficult, do not climb here, at us here both mathematicians and sociology and generally operation does not suffice. 2) thousand classes it is normal, all the same how to reduce complexity we we do not know. And.Net Framework with its cyclical dependences between assemblies is yes, an example for imitation... 3) to develop architecture we are not able, we can tell only on test usages - successfully quitted or not so. Who was able to develop, so it is Straustrup, with its CRC-cards, a method which nobody recalled but to it so in Russian culture since the childhood learn, showing game in the thrown up fool with different possibilities of different persons

11

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: AS> In each layer there is the API, the dial-ups of operations, the data structures and constants. AS> if it would be desirable to have complete control over everything, AS> but thus not to give access to lower layers on a straight line, AS> that everyone higher appears is more volume previous (as includes all that already is more low, but in own way). Well make at top level possibility to work with ready objects of level more low. Then the user of all it API can, if wants, in the project csproj another  for indents which creates itself. All made libraries so are arranged.

12

Re: API and puff architecture

V> All made libraries so are arranged. You don't say so! Show me it on example Roslyn: https://github.com/dotnet/roslyn-projec … issues/462

13

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: V>> All made libraries so are arranged. AS> you don't say so! Show me it on example Roslyn: AS> https://github.com/dotnet/roslyn-projec … issues/462 In what generally a question? How to be picked in xml? Well methods 10 different precisely is. Under the link any trivial nonsense, XSLT involve, if it would be desirable to rewrite files. And within the limits of ideology MSBuild generally dares through variables (<PropertyGroup/>) and the conditional expressions in  - you substitute in proper places variables and you change their values depending on any conditions. Here an example from CSPROJ - generation of different connections to  depending on the selected configuration (variable Configuration): <UsingTask TaskName = "TransformXml" AssemblyFile = "$ (MSBuildExtensionsPath32) \Microsoft\VisualStudio\v $ (VisualStudioVersion) \Web\Microsoft.Web.Publishing.Tasks.dll"/> <Target Name = "AfterBuild" Condition = "Exists (' ConnectionStrings. $ (Configuration).config ')"> <! - Generate transformed config in the project directory, because Web apps pick files from there-> <TransformXml Source = "ConnectionStrings.config" Destination = "ConnectionStrings.config" Transform = "ConnectionStrings. $ (Configuration).config"/> </Target> You as can make file PROJ and transform CSPROJ on a template. https://msdn.microsoft.com/en-us/library/dd465326 (v=vs.110).aspx And architecture at what?

14

Re: API and puff architecture

V>>> All made libraries so are arranged. AS>> show me it on example Roslyn V> In what generally a question?  it is arranged not so. It is impossible to control from level of application how gaps will be formatted. You, for example, did not consult. And it  the project written  by architects.

15

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: V>>>> All made libraries so are arranged. AS>>> show me it on example Roslyn V>> In what generally a question? AS> Roslin is arranged not so.  is a compiler in  byte-code, and questions concerned XML for files of projects, not the source code. AS> it is impossible to control from level of application how gaps will be formatted.  helps to generate the code, gaps and indents in which such what were installed by the user for itself. R they do it did not clarify, but it is the most reasonable approach - I as the user know what gaps and indents to me are necessary in my code is better. AS> you, for example, did not consult. I not the wizard, I only study. AS> and it  the project written  by architects. You are defined with the project: https://github.com/dotnet/roslyn https://github.com/Microsoft/msbuild

16

Re: API and puff architecture

Hello, Vladek, you wrote: V> you are defined with the project: Not,  basically almost to the address questions sets, roslyn project system is future API for operation with projects in the following studio / VS Code. One dirty trick: for today it not public API, it is not finished also it not calculated for operation in a lift-off from a host. In the theory it is necessary initial task to sound, with probability of percent in 80 there even it is not required to write the code. But considering that  Arsen. Shnurkov speech about the subsidiary tool, instead of about changeover actually to designing manages phrases. To perceive as to develop architecture we are not able, we can tell only on test usages - successfully quitted or not so I can wave only with a hand and wish good luck

17

Re: API and puff architecture

S> One dirty trick: for today it not public API, it is not finished also it not calculated and others API at us for you are not present: http://arsenshnurkov.github.io/linux-sh … g-code.htm V> you are defined with the project and you esteem to dock on msbuild, it does not work with specific types of projects, only with generalized MsBuild Item S> I can wave only with a hand and wish good luck I and told. Could something else, would give the reference to the book with a technique.

18

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: AS> and others API at us for you are not present: AS> http://arsenshnurkov.github.io/linux-sh … g-code.htm Ugu. And still it is necessary to consider that besides csproj are necessary sln since the assembly order registers in them (separate geniuses add references to assembly not as project reference, and as the link to assembled library in a shared folder bin). Besides it is necessary to consider conditional build symbols, various perversions in a type targets include and also megatons of knee-bends with links to libraries from  with infernal  in the form of redirection of versions through app.config. In general here all is very sad and is very strongly fastened on  to do something hurriedly. Especially if God forbid speech about  several . Generally only it is possible to be shot. If speech about the utility under myself I would solve business by a simple parcer sln + csproj-files. Did such some tens times,  the variant is normally laid down in 1k lines, rarely it is more. If speech about the general-purpose utility - needs to be known, you try to solve what problem. Because it can easily appear so that initial requirements of type of manipulations with dependences - only the iceberg peak, here any trifle can throw very unpleasant surprises. S>> I can wave only with a hand and wish good luck AS> I and told. Could something else, would give the reference to the book with a technique. Well a pancake who knew, what asking about "how to make puff architecture" you actually were interested how to make the API for editing of csproj-files?

19

Re: API and puff architecture

S> it is necessary to know, you try to solve what problem you are confused. At first you (referring on FDG) said that at design  it is necessary to consider as much as possible wide spectrum of tasks of potential users. And now speak - one specific problem and generally less efforts is necessary to manage one change in a separate case. With such approach generally to designing  it is impossible to admit you. S> I would solve business by a simple parcer sln + csproj-files. It all the same what to tell that the compiler only consists of a parcer, and  it is a hogwash. The parcer loses the position information of tokens in the text and does not contain editing model (thus, it it is impossible to analyze further the subsequent operations of conversion from the point of view of minimization of imported changes in a source code.csproj) the Parcer builds AST, and it is necessary still  an object model with which help it is possible for these AST to manipulate.

20

Re: API and puff architecture

So, a current state of arguing: Q) to me it is necessary . A) you the little fool,  it is difficult,  are not necessary to you, is full ready decisions (more than 10 methods) Q)  are not present,  A) well we would not be soared .

21

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: AS> it is necessary to consider as much as possible wide spectrum of tasks of potential users. The citation . Looked through a topic - everywhere not about "as much as possible wide", and about the main scenarios of usage aka usage scenarios. AS> And now speak - one specific problem and generally less efforts is necessary to manage one change in a separate case. Well so you are defined at last - you  model abstract, or try over an existing infrastructure and existing file formats a specific problem to solve? Also give a reality already, and that at us any  instead of actually arguing would turn out S>> I solved business by a simple parcer sln + csproj-files. AS> it all the same what to tell that the compiler only consists of a parcer, and  it is a hogwash. . The jargon is normal. The title went from typical type API Xxx. ParseYyy (). XDocument. Parse () does not confuse?

22

Re: API and puff architecture

S> you are defined at last - you  model abstract, or a specific problem to solve? So I was defined at once. To me it is necessary . I am interested, as do  generally, abstractly. Clarified that the technique is not present. S> try over an existing infrastructure and existing file formats Existing file formats are a part of requirements. It is impossible to take simply them and to throw out. Therefore even absolutely new  all the same will be to have business with the same formats. S> also give a reality already, and that at us any  instead of actually arguing turns out Yes where was more specific? All reality is already in the first post. I am interested not simply so, not for no reason interest. And I was specific painted, what is necessary to me  and for what. My problem specific in the sense that As the EXAMPLE I resulted specific  existing, and to me is necessary too SPECIFIC, but with possibilities necessary for me. The existing infrastructure was to be analyzed on possibility . Because in this case there is a hope to lower probability of errors of designing. About.csproj you above all painted. With errors truth, specifying that happen Project Reference (in.csproj), Assembly Reference (in.csproj) and links (dependencies) between projects in.sln, only you mixed the second and third concept. Other colleague not in course that if to transform XML by means of XSLT formatting flies. And generally XML is third level, and it would be desirable to change means of the fifth.

23

Re: API and puff architecture

AS>> it is necessary to consider as much as possible wide spectrum of tasks of potential users. S> the citation . 2.1 PROGRESSIVE FRAMEWORKS Designing a single framework for a broad range of developers, scenarios, and languages is a difficult and costly enterprise. They do not say that it is necessary to do so. But specify that if  progressive scenarios it covers as a rule much. And if it covers few scenarios what it is progressive ? There there is a comparing multiframework approach and progressive framework even more low. And so that there is now for handling.csproj it is much faster the first, than the second.

24

Re: API and puff architecture

Hello, Arsen. Shnurkov, you wrote: AS> I Am interested not simply so, not for no reason interest. And I was specific painted, what is necessary to me  and for what. . I correctly understood, what it is necessary for replacing an existing infrastructure sln/csproj/msbuild? And that the question while looks approximately so: "I want to write . To begin with, in it there should be the ..." And on the further questions - "everything that is necessary for me, I already painted", without insults. I any more do not know how once again to hint at the obvious fact, but to make unpretentious API that it was convenient to correct links in projects and entirely to implement editing support csproj or  dependences inside  is  two big differences. And without knowing an initial problem which you were going to solve it , to you it is exact anything good advises nobody. AS> my problem specific in the sense that As the EXAMPLE I resulted specific  existing, and to me is necessary too SPECIFIC, but with possibilities necessary for me. AS> the existing infrastructure was to be analyzed on possibility . Because in this case there is a hope to lower probability of errors of designing. Well a pancake, again the same." I want to make the car. It should have a door and it should go. Though  ready me too arranges ". Where, a metal plate-fly the specific scenario? AKA * I have x * I want to receive y, expending z1 and with additional conditions z2 * for this purpose I  should be able a, b and c. You paint only the last part, and that separate special cases from which first two points you will not recover. AS> about.csproj you above all painted. AS> with errors truth, specifying that happen Project Reference (in.csproj), Assembly Reference (in.csproj) AS> and links (dependencies) between projects in.sln, only you mixed the second and third concept. A pancake, let's read all the same that write to you And still it is necessary to consider that besides csproj are necessary sln since the assembly order registers in them (separate geniuses add references to assembly not as project reference, and as the link to assembled library in a shared folder bin). It is given: Project A with <Reference Include = "somelib.dll"> <HintPath>.\proj\bin\somelib.dll </HintPath> </Reference> project B c <AssemblyName> somelib </AssemblyName> and the C project all with the same <AssemblyName/>, but with another output path. How you correctly define dependences (and an assembly order) without a.sln-file?

25

Re: API and puff architecture

AS>> With errors truth, specifying that happen Project Reference (in.csproj), Assembly Reference (in.csproj) AS>> and links (dependencies) between projects in.sln, only you mixed the second and third concept. S> it is given: project A with S> [code] S> <Reference Include = "somelib.dll"> S> <HintPath>.\proj\bin\somelib.dll </HintPath> S> </Reference> S> [code] S> As you correctly define dependences (and an assembly order) without a.sln-file? Dependence presence easily I will define - I will see in.csproj element Reference instead of ProjectReference. To collect correctly without.sln a file not to a smog, but it does not excite me, because the parsing task.sln is easier, than the parsing task.csproj, in it only three levels - is not present XML and there are no MSBUILD-elements. And it is is specific at me the parsing task.sln it is already solved, me suffices (it is that library CWDev. SLNTools which is engaged in that  solutions) That is for dependence is written down in.csproj for determination of presence of dependence.sln sln it is not necessary. Certainly, well and the code of operation with.sln to rewrite, that formatting was saved. But I asked about designing abstractly if to me give a technique for.csproj for.sln.nuspec.package and.config I will apply it on-analogy. S> I correctly understood, what it is necessary for replacing an existing infrastructure sln/csproj/msbuild? No, incorrectly. I agree and integration. Simply existing implementation of this infrastructure does not solve my tasks. And it is necessary to me, that they dared. S> * I have x S> * I want to receive y, expending z1 and with additional conditions z2 S> * for this purpose I  should be able a, b and c. S> you paint only the last part, and that separate special cases from which first two points you will not recover. I it do to focus SPECIALLY attention on the development task . If I describe the general task, talk leaves in neural networks or still where not there contracts. Tell, "is not present, it is too difficult" and on it arguing ends. On the other hand, to write the feasibility report on that I  presents a pattern of more happiness smaller total efforts of inhabitants of a planet than  multiple framework from microsoft to me while with some difficulty.