Best reading materials for C# 2.0 ERAD (Enterprise Rapid Application Development)
Best reading materials for C# 2.0 ERAD (Enterprise Rapid Application Development)
About "ERAD"(Enterprise Rapid Application Development) : the architecture design uses “custom class” -- hence "Enterprise", it also uses “no framework", "no code generation", and “no strongly typed collections” -- hence "Rapid". From now on, I will use "ERAD" (Enterprise Rapid Application Development), instead of previous "OTTEC" (One-Two-Three Enterprise Computing), to "inherit" some tradition from VB6 "RAD". I know, it is just silly word playing; however, it does tell the general "taste" of a design.
About "reading materials": standards are good, architecture designs are good. However, in-house standards and architecture designs must be short and sweet, and backed by some definitive reading materials. Note that standards and architecture designs must be convincing to cultivate consensus. Training classes are good for that, but too temporal. Writing in-house materials is too expensive and, frankly, far from convincing (“who are you …”). We need to pick up a few “bibles” for the consensus cultivation.
About the architecture: you may ask, "where is your diagram for your architecture design?" Answer: I do not have one, and I do not need one. The reading materials below describe it better than me, why bother reinventing it! -- OK, I understand the need to have a one statement description, so, here it is:
The architecture is designed around using custom-class data-binding, using CSLA’s data-binding (but it uses ICancelAddNew and therefore excludes all fancy generic inheritance), CSLA’s validations, and CSLA’s other small utilities, but excluding EVERYTHING else in CSLA.
------------------
After some discussions, I have to admit that I should almost reverse the order I blogged before http://survic.blogspot.com/2006/08/how-to-learn-net-2005.html#links , and give the following:
1. Unless you have a web task, learn winform first: it is simpler, while has more advanced UI. In other words, if you have a choice between winform and web, use winform, because winform development is rapid, and results more powerful products – unless you really need web.
2. Unless you must use dataset, otherwise, use custom class approach. Note that datasets are fine with read-only or simple update (e.g. appending logs) tasks. So, custom class approach does not exclude datasets.
3. So, the following are "biased" with winform and custom class approach.
4. Read Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET , start with chapter 9 -- I am not crazy. Sure, you must go back to previous chapters for quick references. However, as I said, start with chapter 9, and read other chapters (including chapter 10) only as references.
5. Quickly read my blog (I know I know, but I do not know any other good replacements, plus, I did put “quickly” there ;-) http://survic.blogspot.com/2006/11/minimalist-custom-class-approach-for.html#links
6. Read http://sourceforge.net/projects/blw/. Optionally, other links in (5).
7. Read Rocky’s book, Expert C# Business Objects. However, only read contents on “databinding” (note: because of ICancelAddNew, the whole advanced generic-inheritance mechanism is not necessary; also, its promiscuous use of custom collections is not a role model at all!), “validation”, and utility classes (e.g. SafeDataReader).
Important notes about 7: If you read it first time and only for the purpose of understanding the design of our winform applications, then, make sure that you ignore ALL other discussions, including “undo”, all security features, all remoting (this means all discussions on “dataportal”, including all those limitations of CRUD 4 methods, and “exists”, “criteria”, “command”), web, and web service.
8. Read other chapters on dataset in “Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET”. This is necessary, because Dataset is good for some purposes (read only, or, simple editing like appending logs). Also, knowledge on dataset can reinforce best practices in custom classes.
9. Read other books http://survic.blogspot.com/2006/08/how-to-learn-net-2005.html#links , including general programming and web programming.
-----------------------------
More notes on “no framework", "no code generation", and “no strongly typed collections”:
“No framework” does not mean forbidding small utility libraries. It only means no big libraries, especially no intrusive and limiting frameworks. Note that once you use inheritance and interface in a certain way (typically “template method” or “strategy”), then, you are creating and using “framework”. Although using inheritance should be careful, this rule is certainly not about that. The operative word in this rule is “big” and “intrusive and limiting”. “Big” means that if one or two experienced but “ordinary” (i.e. “application”) developers cannot re-create it from scratch in one week, then, it is too big. “Intrusive and limiting” is that it should not give any unnatural constrains on object model and other aspects of programming. You may say this is too tough; I agree, however, .net 20 is powerful enough, why we need big third party “frameworks”?! Actually this is not just “framework”, this applies to third party controls also. They are fancy and powerful; however, using them everywhere is asking for trouble – unnecessary trouble. The latter is the key. .Net 20 is strong enough that we do not need to use those things in most places. Of course, on one out of a dozen screens, you need one third party control, that is fine. Does that means that we do not study frameworks, especially open source frameworks? No! The way to use them is to tear them apart into pieces, avoid the “intrusive and limiting” pieces, use other “good and safe” pieces, and use the ideas.
“Code generation” makes maintenance difficult. Code snippets are fine; “emit” is fine; however, pre-compile time code generation should be treated as a last resort, and .net 2.0 is good enough that we can live without it, hence, it is forbidden.
“No Strongly typed collection”: even before generics, strongly typed collection is not necessary. On the one hand, it is well-known that large enterprise projects are completed in Java without generics and strongly typed collections for years! On the other hand, dataset solved the problem almost from the very beginning. However, custom-class approach ignored techniques in both java and dataset for so many years. You may say that it takes time for VB6 tradition to die out. However, after generics, after so many years post-VB6, using strongly typed collections is simply inexcusably wrong.
All those three items are good examples that hand-on experiences and prototyping are important in architecture designs. Only hand-on experiences give you the exposure of other approaches (for example, you are “forced” into a Java project, or just the opposite, a project that uses dataset. Also, only hand-on experiences give you a pragmatic attitude – sure, some part of pragmatic attitude comes from personality; however, the real reliable part comes from reality: if you have to do some “maintenance development”, then, you know how bad third party controls, big frameworks, or code generation can be; if you really do the hand-on coding, you will know how bad those strongly typed collects are. Software is all about “trade-offs”, and it is only through hand-on experiences that you know the “weights” of those “trade-offs”. From my experience of working with experienced, intelligent, knowledgeable but high-level architects, I know that it is almost their job that they ignore the troubles (“itches”) that ordinary developers (“application developers”) care most (perhaps it is good that way, "check and balance" I guess). It is very difficult to discuss those things with them, because they already know, honestly, they do know, they just do not care – they do not put enough weight on that. The solution: experienced developers must do prototyping very actively in the phase of architecture design. Do not wait! Once you have a few prototypes, then, you can say something -- all good architects (even high-level ones) respect running code; actually, from my experiences, good architects welcome prototyping.
Note that I am NOT advocating prototyping without big design ideas (if you know me, you know that I am the first to stand up against purposeless so-called "prototyping"). We should always study open-source or source available frameworks. In summary: on the one hand, good architects should welcome hand-on prototyping; on the other hand, good developers should always know a few well-known frameworks.
posted by survic at
6:36 PM
|
3 Comments
