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.

4 Comments

  • <i>Databases need to be viewed as services [...] The database looks just like a set of methods for retrieving/storing/manipulating its data.</i>



    The database is a service providing a set of methods to <i>manipulate</i> its data -- but you actually never <i>retrieve</i> the data. It remains somewhere within the database, where someone else could be manipulating it too.



    All you can get is a <i>proxy</i> object of the real object, which lives in the database. I have yet to find an O/R mapper that fully acknowledge this and elegantly handle it.

  • i agree with the seperation of tiers; however, i find it difficult to justify using webservices as a dataaccess layer (BLL yes but not DAL). just use the native library. its better suited for the job anyway.



    there are some obvious exceptions such as when the cost of connecting to a scarce resource like an AS/400. But in this situation the cost of the connecting to a scarce and difficult resource outweigh the cost of traversing the explicit boundaries of an SOA architecture. but those situations are few and far between.



    -Mathew Nolton

  • Oh, no, don´t get me wrong! I´m not saying, databases should always be hidden behind a webservice!!!! I´m just saying, we should put a facade before them. Make them accessile thru an interface. Just a long list of functions. But of course, those functions should not have a 1:1 mapping to tables!

  • agreed. now if only microsoft would have defined generic dataaccess exceptions as opposed to SqlException versus OracleException versus OleDbException our world would be so much better.

Comments have been disabled for this content.