How to do window development in .net 3.0

How to do window development in .net 3.0


1. To be SOA-WF-enabled, separate “entities” from “services/activities”.

-- It is important for the new wave of Enterprise RAD and “connected applications” that we have fine-grained and guarantee-fully-SOA-WF-enabled.

2. For “services/activities”: Use WF’s activities (which are commands of the command design pattern) for CRUD and façade (“manager”) methods.

-- Note that you must be careful that always treat the result of calling those activities as a new object; never treat them as reference semantics. This is because if we use WF remotely, then, they are new objects, not references. http://forums.lhotka.net/forums/permalink/11975/12387/ShowThread.aspx#12387

-- Also, within the execute method, when it is not local (and when it is local, you should do it the same way), always copy the entities to the original activity’s data members. This will solve the problem that the WF engine will not change the activity’s reference after running execute.

-- Note that because it is proven that we can abstract network and other code via command design pattern, so, it is not necessary to do it if you do not need it – if you do web development, or if you use fat clients directly talking to databases, then, you do not need to inject anything here – keep it simple.

3. For "entities": Use “custom class” approach. Use PONO classes as the entities, no framework is “required”.

4. In the PONO classes, you should use the validation-databinding part of CSLA (the other things are very good for thinking also; but are not "required").

5. For databinding itself, for 2003 (OK, it is not just .net3.0), Use ObjectView, note that your object do not need to implment IEditableObject (for grid’s “in place” editing)

http://sourceforge.net/forum/forum.php?forum_id=420090

http://sourceforge.net/news/?group_id=123313http://jira.nhibernate.org/browse/NH-117http://sourceforge.net/forum/forum.php?forum_id=420090

6. For databinding itself, for 2005, use ObjectListView (has similar but different IEditableObject as ObjectView's; note CSLA object always implements INotifyPropertyChanged, if you do not use CSLA, you need to do it yourself)

http://forums.lhotka.net/forums/thread/6350.aspxhttp://forums.lhotka.net/forums/permalink/4882/4882/ShowThread.aspx#48825http://forums.lhotka.net/forums/permalink/4882/4882/ShowThread.aspx#48825.

7. For databinding itself, for 2005, if you want a context without any framework, use BindingListView (it uses event for IeditableObject -- it can handle object that does not implement IEditableObject; but must implement INotifyPropertyChanged)http://sourceforge.net/projects/blw/

WF, Visual Programming, and Model Visually

Perhaps I should make a second effort to sale WF

WF resurrects visual programming (the glory of VB/RAD). Note that you never know what will be in WF and what is not, as a result, the best way is to make it really fine-grained, so, lets build it from CRUD level. So, all CRUD methods must be activities, no mention those “commands” (“unit of work”, “workflow”, “façade”, “coordinator”, “manager”, or whatever you like to name them).

I know when I say “let entities be entities”, I am against “objects are determined by behaviors”. I never really believe “behavior” thing, because I have been using OR mapping for so long. OR mapping, SOA, and now WF, they all work against OO purist (“behavior”). The reality is that it is not about pure OO; it is about a good compromise for distributed computing.

At least it is a possible usage of CSLA. Note that the databinding core of CSLA will not be touched at all; so, it is still CSLA. Also, the data portal part is also not affected. It makes it simpler: all business objects are split and reduced into “command”.

You ask, what is the purpose again? Visual programming! To support the idea that an end user can develop an application – I know, that is impossible and undesirable – then, it is to support a developer can talk to user to spec the application, and then spec is automatically translated into an application 3 minutes later, i.e., the “analyst’ is the “developer”, real time – isn’t the dream of all of us?!

To realize the dream (I know, we still need OR mapping to get there), we need to make the activities as fine-grained as possible – this is the key against the argument that WF is only for inter-application, because you never know what is for inter-application and what is for intra-application – imagine that you are developing a product for a client. You only deliver the binary to the client; however, the client requests they can customize the product, and therefore they need fine-grained API. You have to make all CRUD available.

If you do not use VB and “visual programming” are dirty words to you, then, try “Model Visually” (the "best practice" from UP or MDA). The strangely, they are the same thing now.

Window Workflow Foundation (WF) is big, and how CSLA (or your framework) can support it

Window Workflow Foundation (WF) is big, and how CSLA can support it

Note: I use CSLA as the “baseline” architecture for easy discussion. Note that I highly recommend you study CSLA; however I do not use CSLA “as-is” – I really do not like the typed collections and limitations of CRUD things. However, this does not affect my recommendation that CSLA is the best material in the market. Note that in the beginning, CSLA is supposedly an educational anyway.


I posted the following on Rocky's Blog:
http://www.lhotka.net/weblog/DoesWorkflowCompeteWithCSLANET.aspx



A. Window Workflow Foundation (WF) is big

(1) WF is “just” an automation scripting tool, just like VBA.

(2) However, just as we can use VB for application development, we can push WF deeper.

(3) Actually, we have the whole COM, simply for VB (OK, I twisted it a little to make it VB centric, but you know what I mean). Of course, just as we cannot create a COM for every object, there must be a limit how far WF can go.

(4) The scripting is XML based (XAML), however, in theory, it can be written by C# etc. Note that I do not mean the “code-behind”; I mean writing the workflow in C# and the IDE translate it into XML.

(5) The analogy can go further: a new generation of RAD is coming back; now, it is enterprise level, so, let's say it is ERAD. The workflow and its visual designer is the beginning of ERAD. You put this with the whole Office scripting, that is the power of M$! Note that because of WF, it is also the MDA. a WF is a more structured (hence more limited but also more supported) "activity diagrams". Now, the flyweight joins force with the super-heavy weight.

(6) Also, it is a structured (hence more limited but more supported) aop loadtime engine (i.e. emit-style engine).

(7) Also, this is a structured threading engine also. Who needs low level threading anymore!

(8) Also, it is a super-lightweight application server. It replaces EJB session beans! For example, it provides transaction services. Also, it requires you do things in a certain way. It is all similar to EJB. Note that I guess nobody now cares about the entity bean anymore; it is replaced by OR mapping, which will be realized by ADOEF-LING in the near future (if MS screws up again, it does not matter, we have nhibernate anyway).

B.How CSLA can support WF

(1) WF activity is basically the workflow object (“command” object). I believe CSLA should help to make all such object as a workflow activity, out of box.

(2) One deeper WF “customization” of CSLA is to remove those CRUD methods into separate classes. Entities are just entities. Those 4 CRUD methods should be split into 4 activities. In short, together with (1), all CSLA database related programming is in “activities”.

As I have pointed out sometime before, the base of CSLA is command design pattern. WF’s activity is also based on command design pattern. In Java history, command pattern was very popular before J2EE, but has been declining ever since. However, because of workflow engine, it seems that in .Net, command pattern will be the dominant design. Note that J2EE also has workflow engines, but historically, it came after J2EE server, and therefore it is only a feature of application server.

(3) Note that for those pure entity classes, they can use rule engine, instead of CSLA’s rule engine. Note that MS’s rule engine now is very simple-minded, it is not really the “inference rule engine”, but it is still more powerful than CSLA’s. Also, it is everywhere, and it is free. It is going to be ad hoc basic-standard.

(4) For performance, the workflow engine must be a singleton.

(5) The thing that is not touched at all in CSLA is the data-binding related features of those pure entities.

A Developer's OOA for Being a Business System Analyst and Why Use Cases Are Important After All

A Developer's OOA for Being a Business System Analyst


------------------------------------------------
A. The Qestions


Recently, I am considering two questions:

1. What is the advantage of a developer being a business system analyst?
2. What is the advantage of object-oriented analysis (OOA)?

Those two questions are related: OOA can be mastered by a developer; therefore, a developer can be a good business system analyst.

I must immediately indicate that this does not mean a non-developer business analyst cannot master OOA. We must remember that the origin of OO concepts (Object-Oriented concepts) is from AI (Artificial Intelligence), which is modeled after natural human thinking. A lot of non-developer business analysts are talented natural OOA thinkers. Further, developer business system analysts must work with non-developer analysts – it is team work, and people must learn from each other: typically, developer analysts will learn a lot of domain knowledge from non-developer analysts; and non-developer analysts will learn a lot of programming knowledge and formal OOA techniques from developer analysts.

Having said the above, the focus of this blog is to point out what developer analysts can contribute to an analyst team, because this aspect is not often said.



------------------------------------------------
B. When


Before I start, I want to point out when this contribution can be especially important. It is after the main architecture is decided, designed, implemented, and completed. After the main architecture is done, the major focuses of all projects are analysis. However, architecture is a continuous effort. In the context that major architecture effort is completed, and analysis is the focus, it is important that there is a built-in mechanism within analysis to address architecture issues (i.e., “derivative requirements”, “architecture requirements”). Again, this “built-in” mechanism is not crucial when the architecture is actively being designed and implemented; however, it is critical afterwards.

For outsourcing projects, customization projects, and configuration projects, it is often that we are in such a situation that the architecture is “completed”. Further, because the completed architecture is not done by the same team or developers who are doing the “configuration” development, for those projects, it is especially important that the analysis explicitly consider and specify architecture requirements.


------------------------------------------------
C. The Answer


Now, let's start. My central argument is that developers’ OOA experience is formal, structured, and intensive; as a result, when developers use OOA to do business system analysis, they can be more focused and more efficient. Immediately I want to point out that being more focused and efficient is not necessarily more effective. Again, it is team work of all analysts, both non-developer-analysts and developer-analysts.


An OOA developer analyst can immediately abstract “use cases” from mockups, and is capable of directly using database tables as “glossary” and use the data as “examples” of the “concepts”. As a result, they can think “use cases” and “entity objects” simultaneously and systematically, and reach a proper abstraction very fast. This is the root cause of many other good things:

(a) They can think about automated (i.e. not screen oriented) testing from the very beginning. Because tests are more dynamic and cover more combinations of scenarios, they help them to get the right level of abstraction faster.

(b) They can think about the “boundary” situations and testing data from the very beginning.

(c) As a result of the above, the result of the analysis is easier to be designed and implemented by developers. Further, because of the right level of abstraction, the implementation will be more stable.

(d) Note that “workflows” and “things” are not as abstract as “use cases” and “entities”, as a result, the latter two have more abstraction power.

(e) Developer analysts read books like “Analysis Pattern”, which can be a rich and power source of right abstractions.



------------------------------------------------
D. Non-OOA (VB6) Paradigm Is Bad


VB6 paradigm is from VB6, and OOA/OOD cannot originate from VB6. However, OOA/OOD can be applied to classic VB development – I know this because I have been doing that for more than 10 years, applying OOA/OOD in C++/Java to classic VB. However, that should be the reason to underestimate how harmful classic VB paradigm can be. Do no make the mistake I made!

Also, non-OOA developers can be business system analysts. However, they have less advantages, and worse, are less compatible with non-developer analysts, because OOA is more “natural”. I know it can be counter-intuitive -- Java/C# are more advanced, however, they are also more accessible to common sense business people.

Many VB6 developers do not know and cannot know OOA. I did not realize this clearly until recently. Note that I used VB6, however, I have been used C++, Java, and .Net the same time when I use VB6. I did not realize the big difference between using-VB6-only and using VB6 as a scaled down version of Java. One important element that I now realize this is from the blog discussion with Vikas (http://survic.blogspot.com/2006/07/domain-modeling-or-data-modeling.html).

Vikas emphasized the difference between OO domain entity model and database design. I did not feel that way, and, frankly, from pure know-how point of view, I currently still do not. However, now I realize that conceptually the difference is indeed critical. I now also understand why Rocky (http://www.lhotka.net/weblog/) emphasizes OO so much. Those are the veterans of fighting old VB6 mindset. I was just too naïve -- I have to admit that. OO is not as easy and natural as I thought it was to a VB6 programmer who had never touched other programming languages before -- even he/she is very intelligent and very smart, and is an excellent VB6 programmer. OO thinking is a paradigm shift.

This revelation hits me very hard. Now I am more a UP guy than a XP guy, simply because XP does not emphasize OO that much – XP almost lets you feel that it can be anybody’s tool, regardless OO or not. As a result, it is more adaptable as a methodology; however, that kind of suggestion that you can do programming without OO is very harmful. Note that I know in XP, you have some OOA/OOD techniques by using some cards. However, that is simply not the mainstream thing nowadays.

http://survic.blogspot.com/2007/01/18-best-practices-from-systematic.htmlhttp://survic.blogspot.com/2007/01/why-up-is-important-and-why-use-cases.html

The “using UP to fight VB6 paradigm” happens so fast, now, I even need to reject my very recent stand saying that “use case” is not important. Again, from know-how point of view, mockups are more important, and the formalities of "use cases" are harmful. However, from conceptual point of view, “use case” is crucial (see below for why). Also, “use case” is better than XP’s “story”, because “use case” implies there is an “OO” context.

You may ask, come on, what is exactly wrong with VB6 or non-OO, especially at the analysis stage? To be frank, it is a paradigm shift, so, it is the whole thing. However, we can still enumerate some.

The most obvious thing is that they are always overly enthusiastic about some implementation details too soon and too much. Such an attitude makes a lot of VB6 developer be incapable of learning "big techniques", and incapable of handling large projects that needs real team work.

The second most obvious thing is actually very ironical: they do not have “concepts” (i.e., objects) in their thinking (only some interweaved “algorithms”), therefore, they cannot use database tables as the concepts, therefore, they treat database and (testing) data separate from serious programming thinking. The last step is the irony: VB6 is supposedly always integrated with database. How to “explain” the irony? If the project is small enough, and the database is technologically bound (pun intended) by those notorious pre-.net data-binding techniques, then, VB6 is great, for anything beyond that kind of toy-like thing, VB6, its paradigm, and its developers create big messes.

In practice (i.e. at know-how level), entity models can be simplified to such a degree that it does not need any effort after you have a good database (the core of my previous arguments). However, conceptually (i.e., logically), they are extremely important – they are the most important thing in enterprise programming. I now agree with Vikas and Rocky totally about it. Again, I disagreed with them in the past, because I did not realize how harmful VB6 paradigm can be, and how much inertia the VB6 paradigm can be.