I have an architecture wich goes like this
Repository -> BO -> WCF -> Web
and vica verse
Repository <- BO <- WCF <- Web
My question is, if I have just simple CRUD operation like just delete a record by its Id, would it be acceptable to skip the BO and go straight to the repository ?
Repository <- WCF <- Web
The answer is, as always in architecture, 'it depends'. You can have architectural layers with or without allowing bypasses, as long as you are clear about what you permit when.
In your case, you simplify the elementary CRUD cases, which is good: the BO code to pass on CRUD is in itself just a meaningless cost. But you also introduce uncertainty about exactly when to use the business object layer: in the extreme case, the system can tend towards treating everything as CRUD, eliminating any value of the BO layer. As an slightly less extreme case, you could get a few BO functions implementing complex logic, decoupled from each other and any object oriented representation of the business domain.
Just be clear about (and write down a few sentences documenting) the principles for when to use which pattern, and be strict about applying the principles.
No, not acceptable - always take the same path :)
As Pontus is basically saying - either way is fine; but you have to choose one method and stick to it; be consistent. If you mix both you're almost guaranteed to get bitten.
As for which one to take - either is ok if it meets your needs, the caveat is knowing what the relevant risks that might bite you long-term. I would almost always take the "BO" approach as the overhead isn't that huge, and it's very likely that you'll avoid a lot of re-work if the demands on the system change; having the BO is definately safer long-term.
My suggestion is to stick with your architecture and going through the BO, particular operations like update or delete which may require business rules validation and other cascading type operations. You may not have any business rules defined now for the entity but you should design it for extensibility.
In some occasions it may be acceptable to bypass your BO for read/retrieve type operations like retrieving a list of something or DTO objects that amalgamates information from several entity for strictly presentation, search or validation purposes to achieve better simplicity or performance improvement in a complex environment.