Databases
StackOverflow2013
Postsdbo
POWeb app architecture advice
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWeb app architecture advice
    primarykey
    data
    text
    <p>The team I work with (3 people) are currently discussing the architecture of a new medium size web application and as you can imagine there are contrasting opinions within the team about how the application should be designed.  What I'm trying to do is post some of these ideas with the advantages /disadvantages to each approach that we know of so the SO community can help us go down the best route and/or achieve a compromise.  </p> <p>Architecture A:</p> <ol> <li><p>Repository layer:</p> <p>Calls to Entity Framework</p></li> <li><p>Service / Business Layer:</p> <ul> <li>Each 'Manager' to have an interface</li> <li>Each 'Manager' to have 2 implementations (1 mock / 1 actual)</li> <li>Methods in Manager classes to call Repository and then apply business logic</li> <li>Each method to be unit tested</li> </ul></li> <li><p>Presentation Layer (MVC):</p> <ul> <li>Managers to be created via some sort of Service Locator pattern</li> <li>Each controller to have unit tests written against it</li> </ul></li> </ol> <p>Architecture B:</p> <ol> <li><p>Service / Business Layer:</p> <ul> <li>Contains only concrete 'Manager' classes</li> <li>Methods call Entity framework directly (eg we're treating EF as the repo)</li> <li>Interfaces may be used but only where there is a need for different implementations</li> <li>Unit tests as and when when required</li> </ul></li> </ol> <p>2. Presentation Layer (MVC):</p> <ul> <li>Manager classes to be created directly</li> <li>Unit test only code that is fragile or of significant complexity</li> </ul> <p>Some assumptions you can make:</p> <ul> <li>Most methods within the app will be database calls with the odd bit of authentication / restricting data returned based on user permissions / etc</li> <li>95% of controllers contain no significant complexity</li> <li>There is no business need to swap out or have different implementations of the Business layer classes.  The business are happy to take the refactoring hit in the unlikely event we have to switch databases / etc</li> <li>The estimated code size including markup etc is about 50k lines (based on the previous version of the web app which is a mess)</li> <li>Development time is tight</li> <li>There is a dedicated QA person</li> </ul> <p>Sorry, if this appears contrary, but my preferred architecture is actually B for a number of reasons.</p> <ol> <li><p>I've worked on projects that are abstracted to the nth degree and it does take a lot longer to make changes to each of the layers,  rebuild in VS,  revise the tests / mock methods / etc and it offers not much return for projects that are essentially simple CRUD applications</p></li> <li><p>The business don't care if the app has the cleanest architecture in the world,  they just want to ship the product quickly without too many bugs</p></li> <li><p>For the vast majority of methods (in all layers) a simple functional test is all that's required.  If the method GetProductById doesn't work,  fix it!  In my opinion a unit test method containing more lines of code than the method being tested just isn't required for simple methods.</p></li> <li><p>I want to be able to right click a method, choose 'Go to definition' and see that actual method source!  I don't want to see the interface definition and then have to lookup the actual method elsewhere.   Sure if everything uses interfaces then swapping to a different database should* be a breeze but realistically that just doesn't happen nor is it likely to happen for this project.</p></li> </ol> <p>In summary,  I'm not against interfaces or unit tests however where there seems to be a proliferation of either that brings little to no benefit I can't see the point.</p> <p>Anyone have any suggestions/ advice?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. UStereško
    1. UStt83
    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. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWeb app architecture advice
      1. USek_ny
      1. VTFavorite
    2. VO
      singulars
      1. POWeb app architecture advice
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. POWeb app architecture advice
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSorry about the formatting, I typed this on my iPad!
      singulars
      1. POWeb app architecture advice
      1. UStt83
 

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