Our view of applications and databases needs to change: Think more services!
After 5 locations of Microsoft DevDays tour throughout Germany and my talk on building a data access layer and several conversations with colleagues and attendees, I´m now convinced of the following:
-How application development currently is "sold" is wrong. Developers still - after 8 years of Microsoft application server - don´t really understand the concept of application server or the value of business logic components. (And I mean "real" business logic with a service oriented interface.)
The culprit I identified: How we draw pictures of applications. In those pictures the frontend still gets to much weight. The business logic is not at the center of attention.
That needs to change!
The business logic has to be emphasized as the "real" application, its heart.
And this business logic then communicates with resources or services to do its job. Plus, it gets triggered by clients. And I mean "triggered". What a WinForms frontend does or a WSH script is firing an event in the business logic. Nothing more.
So any specific frontend is optional. Sure there needs to be some, but it can be veeeery simple, e.g. WSH script calling one method on the BL, setting it thereby off to work for weeks.
-Secondly I´m now sure we need to change our view of interaction with databases (or resources in general). Databases need to be viewed as services, i.e. we need to look at them through a set of interfaces. "We" in this means any client of a database, e.g. a business logic layer.
Clients of databases must not only be free of db API calls (e.g. there should be no ADO.NET use in BL), but also of any SQL statements.
Clients should definitively view databases only through a list of high level methods. Whether these methods are then implemented by a Data Access Layer as inline SQL or a stored proc, the clients don´t care about.
If data access is implemented this way, binding to a database can be as simple as referencing an assembly or accessing a webservice. The database looks just like a set of methods for retrieving/storing/manipulating its data. And those methods mirror the concepts found during requirements analysis. Those methods know of "Customers" or "Orders" etc. They are specific to a problem domain, not generic. They deal with business entities, not abstract entities like tables.
More in a future posting.