Scott’s introduction: http://www.microsoft.com/downloads/details.aspx?FamilyId=92F2A8F0-9243-4697-8F9A-FCF6BC9F66AB&displaylang=en

download: http://www.microsoft.com/downloads/details.aspx?FamilyId=92F2A8F0-9243-4697-8F9A-FCF6BC9F66AB&displaylang=en

It looks much neater than the previous version. Looking forward the official launch.

Problem

Meet 2 weird issue in a simple MFC Dialog based Windows CE application:

1. MFC’s single instance mechanism seemed don’t work (My dialog based app won’t quit, it just hide and wait for activated when user try to run it again) , a new instance always come up.

2. Click "today/start" menu item, the today screen don’t show up, instead it show my dialog app’s UI.

3. Smart menu remain to be my dialog app’s smart menu when today’s screen is displayed.

Solution

Read the MFC code, it does have single instance check by create a mutex, however it seemed that if I hide the app’s main window by ShowWindow(SW_HIDE),  EnumWindow() will not able to find the previous window handle, so MFC think there is no previous window to activate and it run a new instance.  I change to ShowWindow(SW_MINIMIZE), the problem 1 was fixed.

For problem 2, 3, eventually I found the solution from here:  http://www.pocketpcdn.com/articles/today_friendly_dialogs.html 

Question

I have created a dialog based application. It works ok. But when I click Today item in Start menu my program is shown instead of Today screen. How can I fix it?

Answer

This is because Today application is like a desktop on PC. When a dialog has no parent a Today window is considered as a parent window. This behaviour is necessary to get access to popup messages. For example when message about low battery is shown and you switch to another application. The onl way to access this popup message window is to call Today program. But such behaviour is not necessary for windows that could be accessible from menu.

To fix it you should change dialog’s WS_POPUP style to WS_OVERLAPPED.

Problem:

  Visual Studio Team System 2008, SP1 beta1, .Net 3.5 SP1.  After install Team Explorer, every time when I try to open a work item, a error show up:

Could not load type ‘Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemDeniedOrNotExistsException’ from assembly ‘Microsoft.TeamFoundation.WorkItemTracking.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f11d50a3a’.

Found it has been discussed here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3380330&SiteID=1

Solution:

Reinstall VS 2008 SP1, problem resolved.

Todd have a great new blog post about MVC vs MVP. :

 Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern),

Model View Presenter (MVP) Pattern

 

The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model).  The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

 

Here are the key differences between the patterns:

 

·         MVP Pattern

o    View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.

o    Easier to unit test because interaction with the view is through an interface

o    Usually view to presenter map one to one. Complex views may have multi presenters.

 

·         MVC Pattern

o    Controller are based on behaviors and can be shared across views

o    Can be responsible for determining which view to display (Front Controller Pattern)

I previously wrote some notes on this topic.

Some other useful links:

http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

This is just a very simple and rough benchmark test, I use my own desktop computer running Windows XP professional and many process (including the heavy weight Visual Studio 2008) and ASP.NET’s development server which comes with Visual Studio. I believe after deploy it on IIS under Windows Server box will archive much better performance.

I use Apache bench to test, the parameter I used is “-n 1000 -c 100″, means send 1000 requests and concurrent number is 100.

Quick view of results:

Of course a simple .aspx page archive the best performance, MVC add very minimal overhead to it.

Use tag to render user control have almost no overhead ( I believe it has been complied inside, like source level include),  RenderUserControl() have a small overhead.

shinakuma’s RenderComponent() have some overhead in performance since he use “ProcessRequest()” which actually initialize a whole server side MVC cycle.  (Java’s jsp:include have same heavy weight behavior as I tested before.) If we can find out a better solution to archive a much lighter weight performance it would be great.

Details outputs:

Test #1: Simple aspx view (same as below MVC’s view aspx file)

D:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 1000 -c 100 http://localhost:64701/views/Home/Index.aspx
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            -835

Document Path:          /views/Home/Index.aspx
Document Length:        1176 bytes

Concurrency Level:      100
Time taken for tests:   3.500000 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1410000 bytes
HTML transferred:       1176000 bytes
Requests per second:    285.71 [#/sec] (mean)
Time per request:       350.000 [ms] (mean)
Time per request:       3.500 [ms] (mean, across all concurrent requests)
Transfer rate:          393.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   2.3      0      15
Processing:    78  331  71.5    343     515
Waiting:       78  328  71.2    328     484
Total:         78  331  71.4    343     515

Percentage of the requests served within a certain time (ms)
  50%    343
  66%    343
  75%    343
  80%    343
  90%    406
  95%    468
  98%    484
  99%    484
100%    515 (longest request)

Test #2:  Simple ASP.NET MVC (empty controller, simple asp.net view page with default master page)

D:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 1000 -c 100 http
://localhost:64701/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            -835

Document Path:          /
Document Length:        1168 bytes

Concurrency Level:      100
Time taken for tests:   4.296875 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1402000 bytes
HTML transferred:       1168000 bytes
Requests per second:    232.73 [#/sec] (mean)
Time per request:       429.688 [ms] (mean)
Time per request:       4.297 [ms] (mean, across all concurrent requests)
Transfer rate:          318.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   2.6      0      46
Processing:    62  408  71.4    421     531
Waiting:       62  403  71.1    421     515
Total:         62  408  71.5    421     546

Percentage of the requests served within a certain time (ms)
  50%    421
  66%    437
  75%    437
  80%    437
  90%    453
  95%    468
  98%    484
  99%    500
100%    546 (longest request)

Test#3: ASP.NET MVC with another MVC request from inside of the view (refer to RenderComponent in this posts)

D:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 1000 -c 100 http
://localhost:64701/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            -835

Document Path:          /
Document Length:        2133 bytes

Concurrency Level:      100
Time taken for tests:   5.734375 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      2367000 bytes
HTML transferred:       2133000 bytes
Requests per second:    174.39 [#/sec] (mean)
Time per request:       573.438 [ms] (mean)
Time per request:       5.734 [ms] (mean, across all concurrent requests)
Transfer rate:          403.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   2.9      0      31
Processing:    62  543  96.6    562     640
Waiting:       46  539  96.6    562     640
Total:         62  543  96.7    562     640

Percentage of the requests served within a certain time (ms)
  50%    562
  66%    578
  75%    578
  80%    578
  90%    593
  95%    593
  98%    625
  99%    625
100%    640 (longest request)

Test #4: ASP.NET MVC with a simple user control rendered by html.RenderUserControl() from MVCToolKit

D:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 1000 -c 100 http
://localhost:64701/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            -835

Document Path:          /
Document Length:        1212 bytes

Concurrency Level:      100
Time taken for tests:   4.578125 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1446000 bytes
HTML transferred:       1212000 bytes
Requests per second:    218.43 [#/sec] (mean)
Time per request:       457.813 [ms] (mean)
Time per request:       4.578 [ms] (mean, across all concurrent requests)
Transfer rate:          308.42 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   3.2      0      31
Processing:   140  426  85.3    453     531
Waiting:      109  423  87.7    453     515
Total:        140  427  85.1    453     531

Percentage of the requests served within a certain time (ms)
  50%    453
  66%    468
  75%    468
  80%    468
  90%    484
  95%    484
  98%    500
  99%    500
100%    531 (longest request)

Test #5: ASP.NET MVC with same user control rendered by tag

D:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 1000 -c 100 http
://localhost:64701/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            -835

Document Path:          /
Document Length:        1212 bytes

Concurrency Level:      100
Time taken for tests:   4.250000 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1446000 bytes
HTML transferred:       1212000 bytes
Requests per second:    235.29 [#/sec] (mean)
Time per request:       425.000 [ms] (mean)
Time per request:       4.250 [ms] (mean, across all concurrent requests)
Transfer rate:          332.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   3.2      0      31
Processing:    78  401  69.5    421     468
Waiting:       78  398  69.5    421     453
Total:         78  401  69.5    421     468

Percentage of the requests served within a certain time (ms)
  50%    421
  66%    421
  75%    437
  80%    437
  90%    437
  95%    437
  98%    453
  99%    453
100%    468 (longest request)

I discussed this question in ASP.NET MVC forums and get many feedbacks and discussion:

http://forums.asp.net/t/1196142.aspx

MVC makes a web application’s architect quite clear, however in my point of view, MVC is not a great for all solution.

One of MVC’s pain points is handling the form submission. For a simple form submission, generally you need 2 action: ActionShowForm and ActionUpdateForm, the first action show a web form interface to let user edit the form, the second action is for submission. If you use server side form validation, it will be a little bit more complicated (depends on how you display those validation information to users).

Traditional ASP.Net web form can handle above form submission in very simple and straight forward way, with just one .aspx file and one code behind .cs file, complex web form handling is a easy and enjoyable work. It’s also very easy and without too much code to use ASP.NET ajax’s update panel to get fancy update free ajax form effect.

MVC frameworks has been used in Java web developing for a long time, look at what’s Java’s new movement?   It’s JSF(Java Server Face), something really like ASP.NET, it also have something similar to “view state” and “post back”. What a interesting thing it is:  after so many years working with MVC, Java guys are looking to web form alike “new” technology,  and after using web forms for so many years, ASP guys are so exciting about MVC.

In one of my experiment project, I used ASP.NET MVC together with the web form.  MVC is used as the major part of the web site, Web forms are used for all those form handling, they co-exist pretty well.

I create a folder named “forms”, and put all web forms files (aspx and cs) inside this folder. Though it’s ok to put them inside the “view” folder, I separated them because they are different  in modeling. The web forms share the same “Model” part (if it require to access the “model”), I use session data object to pass data in/out the  web forms.

http://theryanking.com/presentations/2007/www2007-microformats-parsing/

some tips on microformats parsing:

* shared “n” and “fn”:

      <span class="vcard">
        <span class="fn n">
          <span class="given-name">Ryan</span>
          <span class="family-name">King</span>
        </span>
      </span>

  fn is "Ryan King"

* "value"

• if children that match .value
• concatenate values

      <span class="vcard">
        <span class="fn n">
          ...
        </span>
        <span class="title">I'm an
          <span class="value">Engineer</span>
          at Technorati.
        </span>
      </span>
    

Title is "Engineer"

* mailto

• omit mailto URI scheme and query string

      <span class="vcard">
        <span class="fn n">
          ...
        </span>
        <a class="email" href="mailto:ryan@theryanking.com?Subject=nice+presentation">
          email me!
        </a>
      </span>
    

email is just “ryan@theryanking.com”

* URL

<a     class="url" href="foo">bar</a>

<area  class="url" href="foo">bar</a>

<img   class="url" src="foo" alt="bar" />

<object class="url" data="foo">bar</a>

the value is “foo”

*

<img   class="fn" alt="foo" src="bar" />

<area  class="fn" alt="foo" href="bar" />

<abbr  class="fn" title="foo">bar</abbr>

the value is “foo”

Useful links:

http://ajaxpatterns.org/Web_API_Patterns

• Basic: Use GET for read-only requests and POST for those which change server state (creation, updating, deleting).
• Simple: You should be able to type a URL into the browser address bar and get a view of the corresponding resource. You should be able to submit a standard HTML form to affect server state
• Authentication: Any authentication is handled with simple API keys and/or cookies; not some custom protocol.

Versioning

  add a version in API URI. e.g.  /api/1.0/method

Data format

How do clients determine which data format they want? There are a few options:

1. use file suffix as data format. e.g. twitter use .xml and .json as suffix for different data format the API return
2. use an additional “format” parameter
3. in HTTP header, with “accept: “.

Web service pattern & anti patterns: http://msdn2.microsoft.com/en-us/library/ms954638.aspx

Anti patterns

#1. CRUD interface

CRUD operations are the wrong level of factoring for a Web service. CRUD operations may be implemented within or across services, but should not be exposed to consumers in such a fashion. This is an example of a service that allowed internal (private) capabilities to bleed into the service’s public interface.

CRUD interface for SOA could be a very dangerous service since it could leave the underlying data in an inconsistent state

#2. Loosey Goosey (APIs such as “ExecuteCommand” and command could be anything in the parameters)

There is virtually no contract. A service consumer has no idea how to use the service. The contract does not provide enough information to consumers on how to use the service.

Patterns

#1  Document Processor

Define or reuse an XML schema to represent request and response messages for your service. Ensure that all public interactions with your service use these schemas.

Generate objects directly from your schemas to speed up development.

There are 2 more patterns seemed not very useful for me at this time.

http://ajaxpatterns.org/RESTful_Service

Common REST Mistakes

When designing your first REST system there are a variety of mistakes people often make. I want to summarize them so that you can avoid them. If any are unclear, ask for more information on rest-discuss.

1. Using HTTP is not enough. You can use HTTP in a Web service without SOAP or XML-RPC and still do the logical equivalent of SOAP or XML-RPC. If you’re going to use HTTP wrong you would actually be better off doing it in a standard way! Most of these other points describe ways in which people abuse HTTP.
2. Do not overuse POST. POST is in some senses the “most flexible” of HTTP’s methods. It has a slightly looser definition than the other methods and it supports sending information in and getting information out at the same time. Therefore there is a tendency to want to use POST for everything. In your first REST Web Service, I would say that you should only use POST when you are creating a new URI. Pretend POST means “create new URI as child of the current URI.” As you get more sophisticated, you may decide to use POST for other kinds of mutations on a resource. One rule of thumb is to ask yourself whether you are using POST to do something that is really a GET, DELETE or PUT, or could be decomposed into a combination of methods.
3. Do not depend on URI’s internal structure. Some people think about REST design in terms of setting up a bunch of URIs. “I’ll put purchase orders in /purchases and I’ll give them all numbers like /purchases/12132 and customer records will be in /customers…” That can be a helpful way to think while you are whiteboarding and chatting, but should not be your final public interface to the service. According to Web Architectural principles, most URIs are opaque to client software most of the time. In other words, your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service. Those components would have hyperlinks that point to other components and so forth. Then you can introduce people to your service with a single URI and you can distribute the actual components across computers and domains however you want.
   My rule of thumb is that clients only construct URIs when they are building queries (and thus using query strings). Those queries return references to objects with opaque URIs.
4. Do not put actions in URIs. This follows naturally from the previous point. But a particularly pernicious abuse of URIs is to have query strings like “someuri?action=delete”. First, you are using GET to do something unsafe. Second, there is no formal relationship between this “action URI” and the “object” URI. After all your “action=” convention is something specific to your application. REST is about driving as many “application conventions” out of the protocol as possible.
5. Services are seldom resources. In a REST design, a “stock quote service” is not very interesting. In a REST design you would instead have a “stock” resources and a service would just be an index of stock resources.
6. Sessions are irrelevant. There should be no need for a client to “login” or “start a connection.” HTTP authentication is done automatically on every message. Client applications are consumers of resources, not services. Therefore there is nothing to log in to! Let’s say that you are booking a flight on a REST web service. You don’t create a new “session” connection to the service. Rather you ask the “itinerary creator object” to create you a new itinerary. You can start filling in the blanks but then get some totally different component elsewhere on the web to fill in some other blanks. There is no session so there is no problem of migrating session state between clients. There is also no issue of “session affinity” in the server (though there are still load balancing issues to continue).
7. Do not invent proprietary object identifiers. Use URIs. URIs are important because you can always associate information with them in two ways. The simplest way is to put data on a web server so that the URI can be dereferenced in order to get the data. Note that this technique only works with URIs that can be dereferenced so these URIs (http URIs!) are strongly preferred to URN or UUID-based URIs. Another way is to use RDF and other techniques that allow you to project metadata onto a URI that may not be under your control.
   If you use URI syntax with UUIDs or something like that then you get half of the benefit of URIs. You get a standardized syntax but have no standardized dereferencing capability. If you use an HTTP URI then you get the other half of the benefit because you then also have a standardized derferencing mechanism.
8. Do not worry about protocol independence. There exists only one protocol which supports the proper resource manipulation semantics. If another one arises in the future, it will be easy to keep your same design and merely support the alternate protocol’s interface. On the other hand, what people usually mean by “protocol independence” is to abandon resource modelling and therefore abandon both REST and the Web.

Overall, the thing to keep in mind is that REST is about exposing resources through URIs, not services through messaging interfaces.

from:http://www.prescod.net/rest/mistakes/