I recieved an e-mail from a client that I hadn’t heard from in a while. I did some consulting work with them on their first .NET project. Apparently it was a “big success”, but that didn’t surprise me because the the folks where were pretty sharp and they worked well as a team.
Was web-services worth it?
On reviewing the finished product my client made the observation that layer of web-services that seperated the user interface and the underlying database.
That isn’t too unusual – there are a few different reasons to employ web-services in a solution. One is to enable you to tuck away complex or proprietary logic while another is to remove the need for client applications to connect directly with databases and accept all thos licensing, scalability and security implications. If the only reason that you implemented web-services is the later, then you will likely end up with a pass-thru CRUD-like implementation. This is especially true if the application is really focused on record keeping/data entry/retrieval as opposed to automating workflows.
My client ponders the question whether the web-services layer represents an uncessary overhead. Well – the answer is *drum roll* it depends.
From a workflow/logic abstraction point of view, most of the interaction logic exists in the client application and the underlying stored procedures in the database. However from a security perspective it really is a good idea to speerate the client from the database because the web-services present only a subset of the underlying database functionality – which (if you do it right) actually reduces the attack surface.
My suggestion would be to stick with the web-services layer – it’s place in the design seems to be justified.
Where should I get my data from?
My client also aksed about building a data access layer and whether they should use some third party toolkit like Castle or stick to the tools that come out of the box. I don’t really have enough experience with Castle to say definitively whether it is the right tool for them, especially since (form memory) they are heavy users of Oracle, and Oracle support usually comes second if at all in the world of community extensions for .NET.
O/R mapping solutions generally come at a price, mostly around getting your head around how their persistence and round-tripping mechanisms work, but once you are over that hump they can give you a pretty decent productivity boost, and some of the newer ones are event developed with an eye on performance. Even Microsoft is taking another stab at this O/R space with LINQ with a special focus on the query mechanism – an area where other tools have struggled because they can’t break into the compiler tool chain as easily.
So what is the wright answer for you (my client)? In all honesty I don’t know, a lot of it depends on how you intend to balance the conflicting business requirements – its a design question, not an architecture question. Please excuse me while I go off on a rant that has been a long time coming.
Why I hate the “architecture” word!
This is not intended to be a architect bashing session, rather I have a problem with the word “architecture” and the amount of baggage that it brings over from our friends in the construction industry. Architecture is a big word, it implies building something relatively large with layer upon layer of support systems, which is ultimately topped off with a pretty facade.
As practioners in the software industry we seem to have taken this and tried to replicate this necessary complexity in software, where in reality – a lot of solutions we build don’t require anywhere near as much code. I think we need to take of the architecture hat, and put on the design hat – design is a much lighter world.
Here I evoke the spirit of Joel Spolsky who has written some great stuff around what design really means. But what I want to say is that a good design is a simple design (or at least as simple as possible) and that a software designer wouldn’t necessarily believe that they need to add code – they might decide that usability (in the holistic sense) of the system might be improved by turning something off – or completely removing a feature.
In the consumer electronics business, some people are actually hired to go through a system and remove components until it stops working – they do this to remove the cost before they go into mass production. We need more of this in the software business.
Now that I’ve had my rant, how does that relate to the question at hand? Well, my point is that you should look at each new application as a different challenge – go into it with your eyes open and don’t assume that the framework that you used in the previous application is necessarily the best one in this case. If you do implement a framework like Castle or LINQ, be up front about how much code you expect to save yourself – and, if you end up writing more code bail out. More code is seldom more maintainable – in my experience (and that includes code generated code).