Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Plain and simple.... <strong>it would be easiest from a complexity standpoint to separate the website and your API</strong>. It's a bit <em>cleaner</em> IMO too.</p> <p>However, here are some tips that you can do to make the process of handling both together a bit easier if you decide on going that route. (I'm currently doing this with a personal project I'm working on)</p> <ol> <li>Keep your controller logic pretty bare. Judging on the fact that you want to make it SOLID you're probably already doing this.</li> <li>Separate the model that is returned to the view from the actual model. I like to create models specific to views and have a way of transforming the model into this view specific model.</li> <li>Make sure you version everything. You will probably want to allow and support old API requests coming in for quite some time.... especially on the phone.</li> <li>Actually use REST to it's fullest and not just another name for HTTP. Most implementations miss the fact that in any type of response the state should be transferred with it (missing the ST). Allow self-discovery of actions both on the page and in the API responses. For instance, if you allow paging in a resource always specify in the api or the webpage. There's <a href="http://en.wikipedia.org/wiki/HATEOAS" rel="nofollow">an entire wikipedia page on this</a>. This immensely aids with the decoupling allowing you to sometimes automagically update clients with the latest version.</li> </ol> <p>Now you're controller action will probably looking something like this pseudo-code</p> <pre><code>MyAction(param) { // Do something with param model = foo.baz(param) // return result if(isAPIRequest) { return WhateverResult(model) } return View(model.AsViewSpecificModel()) } </code></pre> <p>One thing I've been toying with myself is making my own type of <code>ActionResult</code> that handles the return logic, so that it is not duplicated throughout the project.</p>
    singulars
    1. This table or related slice is empty.
    1. POREST based MVC site and/or WCF
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USscottheckel
    1. USscottheckel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks, this seems to be the same as @diggingforfire's response, except your point number 4. Are you saying that I should go more to my third option (both MVC and WCF as REST)? If so, could you elaborate on why this is not redundant?
      singulars
      1. PO
      1. USJustin Pihony
    2. COI was referring to the fact that the API should be driven by "hypertext". I'll clean it up.
      singulars
      1. PO
      1. USscottheckel
    3. COThanks, that was already my understanding of REST, so I should be ok there :)
      singulars
      1. PO
      1. USJustin Pihony
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload