it:ad:patterns:ms_sells_vs_not_good_practices_strategy

Differences

This shows you the differences between two versions of the page.


it:ad:patterns:ms_sells_vs_not_good_practices_strategy [2023/11/04 03:29] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +# IT:AD:Patterns:MS Sells VS (not Good Practices) Strategy #
  
 +
 +
 +<callout type="Navigation" class="small">
 +
 +* [[../|(UP)]]
 +{{indexmenu>.#2|nsort tsort}}
 +
 +
 +</callout>
 +
 +
 +<panel title="Summary">
 +
 +There are times when Patterns and Good Practices seem to fly against what one has learnt from cutting one's teeth as a developer on Visual Studio.
 +
 +I'm going to let you in on a little secret: Microsoft doesn't make any money by making you into a good developer. It's not their focus.
 +
 +
 +</panel>
 +
 +
 +### Sales is their Focus ###
 +
 +Microsoft makes money by selling a very powerful and expensive IDE that helps you develop things quickly for the management that you work for, and buys the IDE license. 
 +
 +As making you a better developer is not their focus, and sales is their focus, they sometimes promote solutions to quick RAD development procedures that are exactly the opposite of good practices.
 +
 +
 +### Examples of what not to do ###
 +
 +Case in point:
 +
 +* SqlConnector up in the ASP.NET layer. Total security disaster as it provides from the UI layer not only direct access to the database, but also makes it ver convenient to know the table schemas at the same time.
 +* ASP.NET's MembershipProvider: totally breaks SOLID/ISP. Totally breaks SOC by combining Authentication with AuthenticationManagement (increasing the risk surface in the proccess).
 +* None of the WinForm, WebForm, or MVC UI controls are backed by interface. There's one single little ITextControl interface, barely used... (it's not as if they didn't know how to use Interfaces...the whole data layer was written by much better developers and each element is backed by interface (ie, SqlConnection is backed by IDbConnection, etc.)
 +* Linq Extensions in `System.Linq` namespace, rather than `System` namespace (Linq is not a broblem boundary in itself:[[IT/AD/Design/Technical Patterns/Namespace as problem boundary strategy/]])
 +* System.Data.DataSet in System.Data (automatically ensuring that ASP.NET UI always has access to Db connections).
 +* Entity Framework's `Include` extension method is not more generic (when it could have been) so any Repository that needs to allow an Include specification, drags a reference to EF to higher layers.
 +* Entity Framework's Entity attributes (Key, Index, MaxLength, that kind of stuff) was also put in the EF assembly, rather than be more generic. 
 +    * Another way of they could have done this is separate generic Entity concepts from Entity tracking...so that other vendors could use Entity assembly, without needing EF in totality. 
 +* MVC's Authorisation attributes -- Authorisation should be a more general concept, attached to Business Domain Service operations. 
 +    * It should also be applicable to API boundaries when required, but it should not be *only* applicable to API boundaries.
 +* Same for what they did with WCF.
 +* No built in mapping solution. Without it being in the Framework, the natural inclination is towards Monolithic applications, with no versioning at the API interfaces.
 +* etc.
 +
 +### MSDN Patterns and Practices ###
 +
 +It's not *all* bad. They take the profit they make out of selling Visual Studio and use it to fund MSDN articles on how to be a better developer...