Architecture of a class library RRS feed

  • Question

  • I have been pouring over books, forums and guidelines, but every plan for designing a layered architecture seems to auume some sort of user interface. What I am looking to do is design a class library. Would the public calls make up the presentation layer? If thats the case, and I'm supposed to do the "work" in the business layer, then wouldn't the public interface be, well, empty of any logic?

    I am confused at how to go about layering a class library that offers a public interface, performs work and verification, then outputs/returns data. I may be missing something obvious, but, honestly, I'm completely lost as to how to begin structuring this into layers.

    Any help is appreciated

    Friday, September 9, 2011 3:36 AM

All replies

  • Your creating an API so think about what features the API will provide.

    Let's use an existing API as an example, the System.Text.RegularExpression namespace. What features does that have?

    Well it might appear to only have one feature, to determine whether a string matches a regular expression pattern, but it has other features, for example it also provides a find and replace feature, allows groups to be captured, allows regular expressions to be compiled... and so on.

    So what is the architecture of all this? Well ... I don't know! and I don't know because all the architecture is behind a small number of public classes, RegEx, Match, Matches etc.

    These small number public classes are the top layer of the architecture.

    To the callers of the API the architecture should be meaningless. It shouldn't be important.


    For the developers of the API it is though. So we have the top layer so what could the next layer be... well the next layer might be a collection of parsers that perform each of the tasks, there might be an input text parser, a regular expression parser, a find and replace parser that uses the previous parsers, and so on.... what about the next level down, well the parsers might need a tokeniser and for the most part this is shared with all the parsers...

    so... one way to look at layering the API is different levels of abstraction. At the bottom layer everything is abstract and general and as you move up the layers these abstractions/generalisations are combined to make something a bit more specific, and the next layer up these bit more specifics are combined to make things that are even more specific until eventually you have something that does something concrete.


    This isn't the same as the layered architecture that you might read about with the data layer and business layer and service layer etc. The above is really the layering that happens in each of those individual layers but if you can get your head around that concept then it's a small step to take it further.

    Anyway hope that helps and always it will be good to see what others say. It's a good forum for discussions and different point of views.

    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    • Edited by Derek Smyth Friday, September 9, 2011 9:38 AM
    Friday, September 9, 2011 9:35 AM
  • Thank you for your input, it did help a lot

    So, to reiterate (for my own benefit) an API is not really MEANT to be smooshed into the traditional layers. That maybe planning this API as "Layers of abstraction" with each one doing its own little part.

    I guess the comfort (if you will) I was hoping to find in the traditional model was a fairly clear definition of what is expected in each layer...basically, I'm a programmer trying to plan for a large API. I can see what classes, etc I need to make, but I am wary of a blurring of the lines of responsibility as things become more complex. Architecting a system is a new bag for me, and darn it, I want clear delimiters! sigh.... its never easy

    Friday, September 9, 2011 11:39 AM
  • There are some standard "layers" in a sense. The layers aren't exactly the same, but the philosophies are similar. The problem is that the layers vary from project to project. As in all architecture, the goal isn't to memorize some set of rules, but to evaluate your specific project and decide which rules you should apply and which rules don't make sense for your situation. From the larger APIs I've written, there are several layers which appear pretty often, but they are not necessarily required and may not make sense for all projects. So, take it all with a grain of salt. Most projects don't have all of these, just pick out what you need or add new ones as they make sense.

    First, the first layer you want to define in almost any project is the interface layer. Decide exactly what behavior you will expose and how you will organize those behaviors into externally-visible entities. This is similar to the presentation layer in that it is organized by what makes the most sense to outside users. It doesn't need to correlate at all with actual implementation. This is the layer Derek was describing.

    Along with the interface layer, you'll need to define all of the DTOs you will need to exchange data between your library and the outside world. Below the interface layer, you will need a mapping layer to translate the DTOs to the classes your library uses internally and back again. Your translation layer may also perform input and output validation.

    Below that, it really starts to depend on your project. Typically you will have an actual "logic" controller right below the translation layer. The role of this controller is just to wrap underlying logic. For the regex example, the controller may have the "Find" method, which internally calls the regex parser to match, stores the current match position, and returns the result. It doesn't implement any of its own functionality, it just wraps and organizes the implementing classes.

    Below the controller, you put the actual classes which do the work. These all vary wildly - you just write whatever classes you actually need to implement the behavior you need. There are no real rules except for normal good design principals.

    That may be the end, or you may also need to implement extra layers for data persistence and retrieval or other business logic which isn't handled in the translation layer.

    All of that is a really long way to say, implement the layers you need to hide your details from the outside world and separate concerns, but don't waste time implementing layers that you're not going to need. It takes a lot of experience and concentration to find the right balance between good architecture and the YAGNI principal. Complete beginners usually have no architecture at all, they just throw things in. Well-educated programmers usually go insane on architecture and have huge complicated messes for very simple problems. Your goal should be to get exactly what you need to solve exactly what you need to solve.

    Check out My Blog for tech news, development tips, and other information for geeks like me.
    Friday, September 9, 2011 2:36 PM
  • Ok one of the first things a developer should learn when working on architecture is Test Driven Development.

    Architecture is difficult and as Tim has highlighted it either becomes a mess or it becomes over engineered (my current project has an over engineered smell about it). What Test Driven development does is it puts the breaks on architecture and helps promote 'just enough' architecture to get the job done.

    TDD also lets the architecture grow and change easier over time and that's the important thing; the most important thing. You've got to be able to radically alter a design safely and that's what the tests provide.

    If you don't know it already learn TDD as a means to improve your ability to architect a system.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Monday, September 12, 2011 7:58 AM