I’m interested in why most of Microsoft and some other developer’s demons about writing apps mostly begin with the creation of a database? The design of the app will more or less in that case be driven by the database schema, after the database in place the Data Access Layer will be built and the entities will mostly reflecting the database schema. A data base like Microsoft SQL Server is a relation database, so our model will more or less be a relational model instead of a more object oriented model. That can make it harder to use good design patterns and principles to solve some Implementation problems. OO has a rich toolset for modeling the domain than the relation model.
If we start to focus on the domain model first and implement it, our entities will be created out of our domain model instead. We create our entities, our Repositories. We don’t need to focus on what the data source looks like or how the data should be stored. When the domain model is implemented and tested we start focus on the data source and select the right data source based on how our domain model should be persisted, mostly it ends with a database of any kind.
Microsoft and other developers (including me) articles are mostly technical focused rather than helping people build apps with their tools in the best way. I also think that is one reason so many .Net developers build horrible apps with bad quality and are hard to maintain etc.
On a forum I notice a question like this “My boss told me that I could build ASP.Net application without using a single line of code, because it’s what Microsoft told him, so I wonder how should I start building a web shop, please help me I’m not a developer”.
I think we all need to be better on writing "How", “When” and "Why" (More best practice).
Whose fault is it that so many .Net Developers uses the SQL Data Source when building “enterprise” apps and use drag and drop from a database?