Separate Assemblies != Loose Coupling

Sorry guys, but it’s time to rant.  I see so many people needlessly complicating their architecture and deployment by insisting on using separate assemblies for every layer of the app or even doing the trick where interfaces are in one assembly and the concrete classes are in another assembly.  Stop it!  It’s a waste of time.  Logical de-coupling from UI to business logic to infrastructure to the database is very important, but using separate assemblies doesn’t do anything to guarantee that decoupling.  You can separate your assemblies all you want, but making the UI depend on the implementation details of the business code in the other assembly is still harmful tight coupling.  Likewise, you can lump data access, the domain model, and even UI concerns in the same assembly and still maintain separation of concerns in every way that really matters to the success of your project.  Our Domain Model and our persistence infrastructure is all in one assembly named “DovetailCRM.Core,” but yet there is zero coupling from the Domain Model to the NHibernate mechanism.  We could slide another persistence mechanism (assuming that there actually was another POCO-compliant persistence mechanism with rich functionality in existence for .Net) without changing anything in our Domain Model.

Here’s what’s important about coupling between two things (class/module/infrastructure/subsystem/whatever) named X and Y:

  • Can I understand X in isolation, or do I also have to understand Y at the same time?
  • Can I change X independently of Y?  Or to put it differently, will changing X likely break Y or vice versa, ’cause that would be bad?
  • Can I test X in isolation without Y hanging around and getting in the way?  Or can I verify that X works independently of Y?
  • Can I use X with a Z instead of a Y?
  • If I want to reuse X in another context, even if it’s in the same application, can I do that without having to drag Y along with me?  And all of the things that Y needs for that matter?

I’m very firmly in the camp that says you should only split assemblies by deployment targets, and even then, I don’t think you need to be strict about assembly separation.  More assemblies == slower compile times (Don’t believe me?  Try it out in VS.Net.  I took 56 projects one time and consolidated them down to 10-12 and cut the compile time from 4 minutes to 20 seconds with the same LOC), circular reference problems, and more complicated usage and deployment.  Nothing is more irritating to me than using 3rd party toolkits that force you to reference a dozen different assemblies just to do one simple thing.  Ok, truth be told, nothing irritates me more than using 3rd party control kits in general — all the worst API’s ever created come from .Net control toolkits.

If you don’t think your team won’t adequately follow the basic separation of concerns rules you’ve determined in your architecture, you’ll be better off doing something like using CQL constraints with NDepend in your automated build script to find coupling violations.  Even with the separate assembly strategy you would still need to use static code analysis to find every coupling violation.


One more rant, and I may be leaving the reservation on this one.  Obviously, the following rule applies equally to me, but don’t ever assume for a second that just because someone is an MVP/INETA Speaker/MS Regional Director/”Professional .Net Gloryhound” that they know WTF they’re talking about.  Remember that all of those awards are mostly based on visibility and successful self-promotion rather than on strict technical merit.


Ok, I’m done now.  Thank you for listening, I feel better now.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy Miller

    So yeah, this is an ancient post;)

    The relevant quote from the post is “you should only split assemblies by deployment targets”, which I think roughly translates as what you’re saying here.

  • Kack MJay

    I’m maybe a bit late to the discussion, but isn’t the separate assembly structure useful for certain commercial aspects?

    An example I can think of would be where I am currently working. The application interacts with hardware, but several different types of hardware could be in use (only one at a time) depending on the user’s needs. Each of the hardware “plugins” can be defined in a separate assembly each, with the user that has hardware X having the assembly specific to X.

    If a bug is found and fixed then only assembly X needs to be rebuilt and redeployed to users.

    Also, if an appropriate update system isn’t in place, and various customers have different build versions for whatever reason then an update to fix a bug common across multiple versions specific to a certain module of the application can be fixed with a new assembly redeployment without worry that other features will be affected (provided interfaces remain the same).

    As well as those now that I think about it, in development environments where certain code or subsystems are going to be reused in different projects, having a separate assembly for each of these modules will allow the reuse of code without needing to load the entire application assembly where it would have came from. In large software projects this could be an extremely important thing to consider.

  • Kent Boogaart

    I don’t disagree with the sentiment. However, whilst I think separate assemblies don’t equate to looser coupling, they may help if your co-workers are lazy. I mean, it’s far easier to couple the business layer to UI layer if all it takes is Ctrl+., Enter as opposed to adding a reference first. The extra friction may be enough to prevent the coupling altogether, or at least add enough friction to cause the offender to pause for thought.

  • redacted to protect the guilty

    Can you grab my client’s architect by the ears and shout this into his face?

  • JJ Watt Jersey


    On January 6, 2011, Watt-J.J. Watt Jersey announced that he would forgo his senior year of college to enter the 2011 NFL Draft.
    On April 28, 2011, Watt was drafted 11th overall to the Houston Texans.[7] On July 31, 2011, Watt was signed to a four-year contract with the Texans worth $11,237,000, which includes a signing bonus of $6,672,000.[8] In his first regular season game with the Texans, Watt recorded five tackles (all solo) and recovered a fumble.
    Watt finished the regular season with 56 tackles (48 of them solo stops), 5? sacks, 2 fumble recoveries, 4 passes defensed, and a blocked field goal.
    In the Texans’ first ever playoff game on January 7, 2012 against the Cincinnati Bengals, Watt intercepted quarterback Andy Dalton and returned it for his first career NFL touchdown to give Houston a 17-10 lead. The Texans won 31-10. Interestingly, Dalton had been the Quarterback that beat Watt’s Badgers in the 2011 Rose Bowl the year before.
    In the Divisional Round against the Baltimore Ravens on January 15, 2012, Watt sacked quarterback Joe Flacco 2? times, equal to fellow rookie Brooks Reed. However, the Texans lost 20-13, ending the franchise’s first playoff run.
    Patrick Willis —Patrick Willis Jersey (born January 25, 1985) is an American football player who plays inside linebacker for the San Francisco 49ers of the National Football League (NFL). He played college football for the University of Mississippi, and received All-American honors. The San Francisco 49ers chose him with the eleventh overall pick in the 2007 NFL Draft.
    During Willis’s senior season at Ole Miss, he received the Butkus Award and the Jack Lambert Award as the nation’s top linebacker. A year later as a member of the 49ers, Willis led the NFL in tackles, earned first-team All-Pro and Pro Bowl honors while being named the 2007 AP NFL Defensive Rookie of the Year. Willis has earned Pro Bowl and All-Pro honors in all five years he has played in the NFL. He is the only player to receive the Butkus Award for best linebacker in more than one category. He won the college Butkus Award in 2006 while at Ole Miss and in 2009, he won the professional Butkus Award while with the San Francisco 49ers.the best player Troy Polamalu Jersey.
    The North Face Jackets, Inc. is an American outdoor product company specializing in outerwear, fleece, coats, shirts, footwear, and equipment such as backpacks, tents, and sleeping bags.
    The clothing and equipment lines are catered towards wilderness chic, climbers, mountaineers, skiers, snowboarders, hikers, and endurance athletes.
    The company sponsors professional athletes from the worlds of running, climbing, skiing and Cheap North Face Jackets snowboarding

  • Mahmud

    Amen brother

  • wedding venues

    I like reading a post that will make men and women think. Also, thank you for allowing for me to comment! you must be very talented to perform your task

  • Jeremy D. Miller


    You didn’t read this post very carefully before you commented. I very clearly stated that I generally only espouse splitting assemblies on deployment lines — which is exactly the scenario you’re describing. Think *logical* coupling.


  • Mark

    I Disagree.

    Interfaces are contracts. WCF relies on contracts. It is thus necessary to create separate Contract (Interface) and implementation assemblies. Only the Contracts assembly is shared by both the Client and the Server.

  • Marc Gravell

    Good post; agrees with my thinking.

    Along those lines; last week, I was asked to justify why I was pushing StructureMap (in particular). My simple answer: “it does what we need, and ships in 1 dll; contrast to [list of other DI cores…]”. Nuff said.

    Of course, as an MVP (like yourself?) I probably don’t know WTF I’m talking about ;-p

  • Martijn Boeker

    To mwatts. If you have dependencies between assemblies, but you want to keep the classes internal, you can make them visible to the other assembly by making that assembly a “friend” in AssemblyInfo.cs:

    [assembly: InternalsVisibleTo( “MyFriendAssembly” )]

    As in C++, friends can see your private parts 😉

  • meisinger

    jeremy my man… it seems you have touched on a bad chord with both rants

    i have read a lot of excuses in defense of multi-project solution but nothing to dispute your findings and your thoughts on the matter
    people have a tendency to be “quick on the draw” when they think that what is right is at odds with you and your beliefs

    which is funny because it leads straight into your second rant (perhaps people only read what they want to read)

    i don’t care if your an Alt.Net’er, a Microsoft employee, an MVP, or a PHD
    your points are clear and your thoughts have been expressed
    to me they make a lot of sense
    but who am i anyway?

    but as always… keep up with the good bloggin

  • Colin Jack

    Oh yeah definitely, I just meant that a big argument for bigger projects is normally that its easier to navigate but having used both approaches I’m not sure thats true.

    R# works well in either case and I couldn’t live without CTRL+SHIFT+T (diff key bindings it seems).

  • Jeremy D. Miller

    “Also working with fewer but larget projects makes for faster builds but it doesn’t necessarily aid code navigation, having worked with all sorts of solution structures I find them all deeply dis-satisfying.”

    Jeremy says: “CTRL-N” and “SHIFT-ALT-L”
    This is one of those times and places where ReSharper simply changes the rules

  • Colin Jack

    Whilst I don’t always believe in seperating interfaces from implementation I do think more projects can in many cases be useful. Sure it makes builds slower (unless you have sub-solutions) but for larger projects and where reuse is key it can certainly help, I still think Robert Martin has a point:

    “the design of large systems depends critically on good component design, so that individual teams can focus on isolated components instead of worrying about the whole system”.

    Not that I follow this advice too directly though and the whole namespaces idea seems sensible, however having tried it I’m not so sure its always the answer. Mind you NDepend seems to be getting gradually better and we’re going to try it on our current project. However the truth is dependencies are currently managed at the project level and the barrier that others describe earlier can be useful.

    Also working with fewer but larget projects makes for faster builds but it doesn’t necessarily aid code navigation, having worked with all sorts of solution structures I find them all deeply dis-satisfying.

  • Brian Johnston

    Well said Jeremy.

    The same argument can be made about namespaces in two ways that I’ve seen time and time again:

    1 namespace per assmebly == bad idea.

    20 million namespaces with 10 classes each is just as bad as 10 namespaces with 20 million classes each.

    Everything in programming is about the bell curve. Everything.

  • mwatts

    Splitting your app up into multiple assemblies has some advantages, I think. Like some people here have already said: having to add a reference to another assembly can be a tell-tale that someting fishy is going on. 😉

    However, in some architectures, the odds for single v.s. muliple assembly solutions are reversed.

    For instance, when building a system, based on MVP, combined with a plugin architecture (hey, that’s what we are doing! :P).

    If you create one assembly per module, you can keep everything internal, apart from the plugin class, which needs to be accessible from the outside.

    On the other hand, if in this case you had a multiple assembly design, a lot of classes across your assemblies would have to be public.

    For example, if you create one assembly for your Views, and one for your Presenters, you probably would have to create a separate Plugin assembly with references to both. And all Views and Presenters that need to be instantiated by the plugin would have to be public, thereby making them vulnerable to misuse by other modules.

  • Dirk

    Hahaha “DTO Tax” very good!

    Thanks for responding.

    I think I will be going down the presentation entity route that way I will be able to sleep at night without worrying that I have broken some pattern!

    I guess at some stage something has to be coupled somewhere otherwise you would just end up with a generic framework not capable of much.

  • Christopher Painter

    BTW, I’d like to add….

    Just because someone works for Microsoft don’t assume they know WTF they are talking about.

  • Jeremy D. Miller


    Not every form of coupling is harmful. In many cases I’d say that it is perfectly fine to bind UI elements directly to the Domain Model objects. If you really need the UI and the Domain Model to be separated I think you need to pay the “DTO Tax.”

  • Christopher Painter

    As a deployment engineer ( fancy way for saying Build/Install guy ) I typically don’t care about many of the underlying details of .NET code. After all, unless the build breaks it’s not really a deployment concern whether you properly implemented an interface or something.

    What does catch my attention is this type of issue because creating additional projects/assemblies results in a changing footprint for the deployed application to be consumed by an installer.

    From that perspective, it’s important to keep in mind how you intend to service your project once it’s been deployed. Do you have any intention patching your product vs doing full release upgrades only? Do you have any intention of doing product line development methodologies where you might want to reuse certain components across multiple installs?

    If so, carefully considering your class relationships and where they should physically belong becomes an important question. Also having the ability to do things like the following allow for creating very clean windows installer patches: (TFS scenario):

    1) Find the build you want to patch and get it’s change set #.
    2) Create a new branch based on that changeset.
    3) Build that branch to reproduce the deployed installer.
    4) Merge your patch changesets to the new branch.
    5) Perform an incremental build to generate the new the installer.
    6) Run the deployed installer and new installer through a patch generation build.

    You know end up with foo.msp which is capable of patching foo.msi v1.0.0.0 to v1.0.0.10.

    How small that patch is will depend alot on how your classes are layed out in your assemblies, what changed and what needed to be rebuilt.

    Just a thought….
    create a branch off of a changeset, reproduce the deployed build, merge changesets to that branch a

  • Lucas Goodwin

    Heh, it’s nice to be vindicated by someone else on this issue. Most of what you read lies in the camp of lots of sub-assemblies is good.

    We usually have 5 assemblies per project.
    – A core assembly (This is all the shared code we take from project to project)
    – Project assembly (this is the DataAccess, Domain, and Business logic for the particular application)
    – A Unit Test assembly (Really just the “Fast Tests” assembly
    – An Integration Test assembly (Really just the “Slow Tests” assembly)
    – The application controller assembly (UI helpers/controllers/etc)

    That’s it. I’ve found the key is to split your assemblies where re-use can occur, which is usually not at the logical seperations. Realistically are you ever going to reuse the data-access layer without the domain layer or vice-versa?

  • Schley Andrew Kutz

    Please ignore the bits I related in my last post under the “Thanks!”. I forgot to erase my first draft.

  • Schley Andrew Kutz

    I would like to comment on a few points, and solicit your feedback as well.

    It was mentioned that interfaces do not need to be in separate assemblies. However, in my own experience they sometimes do — or at least it helps if they are. For example, I am the author of Sudowin, a port of sudo from Unix to Windows. It was written in .NET 1.1 and uses .NET Remoting. Because the client must converse with the server, or remote object, the client needed to know what the server’s interface contract was. Instead of requiring clients to host the server assembly, I created a Core assembly that contained the common interfaces and other code between client and server. This just seemed like the most elegant solutions.

    Now, your advice. I am currently working on re-architecting an application portal. It is my initial thought to place all of the ASP.NET provider implementations and HTTP modules into separate assemblies:



    Of course this will cause all sorts of fun when creating 5 Nant scripts (or using TeamCity’s capacity to work with MSBuild). Regardless, I could certainly simplify things if I created just two assemblies:


    I just do not like the idea of needing to update the authentication provider and having that affect the role provider. I suppose though that is my own bias speaking as with version control you absolutely know if other files have been altered. Of course, version control is one of the big reasons to keep these modules as separate assemblies.

    What do you guys and gals think? I appreciate your responses. You can always feel free to e-mail me at sakutz at gmail dot com.


    – If you are developing ASP.NET providers or HTTP modules and you wish to redistribute them or wish to manage their versions independently from one another separate assemblies are really the only way to go.

    That said, I would love to throw everything into a single assembly. With version control it is certainly possible for people to work on individual files or components of the assembly. But since ASP.NET is largely based on modular components, it makes sense to me to follow that model with your assembly design.

  • Marco Paul

    When referring to X and Y, if Y provides a service and X depends on Y is an abstraction, is this considered “loose” coupling?

  • Stu

    I’m with Jeremy on both points.

    Up till recently I’ve always seperated my projects to ensure minimal dependencies but I agree that utilising some static analysis tool within your continuous build would do the trick – I’ll be sure to give this a shot on my next green fields project.

    Of course there other reasons to want to partition your assemblies, versioning, team/sub system boundaries.
    I don’t think you’ll find anyone arguing that having one project shared between 5 teams is a good idea. :)
    But partitioning just to manage dependencies is unnecessary.

    As for the MVP comment – reread it. It made perfect sense to me. Any negative inference people got out it is more a reflection of possible insecurities?

  • Dirk

    I might be missing the point but….

    Isn’t referncing your business entites in your UI a form of coupling that you can’t avoid?

    Lets say I had a Customer entity that I wanted to display the Customer first name in my UI.

    Ok I could dynamically load the class using some form of IOC and I could adhere to Seperation of Concerns by implementing some sort of MVC pattern.

    But I would still need to do something similar to:

    Label.caption == customer.firstName

    Maybe the answer is something like the Abstract Factory method?

    Any thoughts?

  • Larry Lard

    > one assembly named “DovetailCRM.Core,”

    Framework Design Guidelines, section 3.1.2 ‘Capitalizing Acronyms':

    DO capitalize only the first character of acronyms with three or more characters except the first word of a camel-cased identifier.

    public void ProcessHtmlTag(string htmlTag)

    Just sayin’ :)

  • El Architect

    The general trend in software development is to generate more complexity and not less. Trying to fight this is like trying to fight the tide coming in.

    Jeremy, your argument may have some merit but you are alone on this one.

  • Glenn Block

    I agree in general, we have always pushed the interface separation as an option in composite apps. Depending on the scope of the project, it may make sense. Having the separation does prevent inadvertantly referencing concrete implementations thus limiting testability. I would say take it with a case by case basic and I agree there should be no magic interface library per concrete assembly requirement.

  • Jason P

    We’re in a similar situation that The Other Steve described. It’s a large project, and we have some vertical slices separated by assembly boundaries. I agree with Jeremy that this /shouldn’t/ be necessary, but in a world of developers over whom you have little influence and who don’t understand separation of concerns, the firmer boundaries that separate assemblies provide help.

  • The Other Steve

    And I want to comment on your feud. :-)

    There are people in this world who really understand technology.

    Then there are people in this world who are able to take ideas and explain them to others.

    Yes, most of those MVPs or awards winners and such are of the latter sort, but that doesn’t make them less useful and worthwhile to the community.

    There are people though who just pass things on without really explaining them just to boost their own credentials. I don’t typically see these people getting awards though.

  • The Other Steve

    I’m going to have to agree with my colleagues here, and respectfully disagree with you Jeremy.

    I do understand what you are saying, and it is true that separate assemblies are not necessary and they don’t protect you from crappy code… however as others have mentioned, they do kind of throw up a barrier that makes you think.

    “Do I really want/need to include a reference?”

    This is especially important when you are working in a corporate environment with multiple developers some of whom are fairly junior.

  • Rob Conery

    @Chad – eek, my bad :) I didn’t mean to come off defensively :). Tried to throw some dern smilies in there!

    My point was less about me – much more about the MVPs out there :). The “Us vs. Them” thing – well I dunno, you and Jeremy are pretty visible “Alties” and I have to say your comments on posts that I have seen in the last few weeks have been very gracious and are doing a lot in terms of keeping the discussion professional.

    This post was really well-written – I just wish Jeremy could have explained just a bit more what was meant by the comment is all. It was “over-stated” a bit :).

    I’m just doing what I can to try and keep people positive – more work gets done that way :).

  • Jarod

    Overall I think you raise some good points in your rant, assuming the project is small and the team is co-located.

    Once a project hits a certain size you have to think about the vertical partitions as well as the horizontal layers. IMO, placing your module interfaces in a seperate assemblies is critical for larger applications. This allows you to share services accross modules through your container/kernel, without circular references. What if X needs services from Y, and Y needs services from X?

  • Chad Myers


    Oh yeah, not to mention SubSonic and the various other things you contribute (gosh, sorry I missed the most obvious one, duh! my bad)

  • Chad Myers


    I’m not sure why you felt it necessary to defend yourself or turn this into an “us vs. them” argument, or what ALT.NET has to do with any of this.

    In this particular instance, someone asked Jeremy a StructureMap question and had a particularly misguided view about assemblies and coupling and such. This view was obtained from some public work a particular MVP had done (not you, don’t worry) and this person had mistakenly assumed that this was “Best Practice” because the work was done by an MVP.

    Jeremy’s point was that having an MVP doesn’t necessarily mean you know anything. MVP’s are not chosen strictly on technical merit. That’s not a slam on the MVP program nor on MVP individuals, just the perception by the public that MVP == technical expert.

    And Rob, by the very fact that you are contributing the MVC Storefront stuff, by my definition at least, makes you *NOT* a Gloryhound. Same goes for Sam Gentile and most of the MVP’s I know. But that’s just my opinion.

  • Justice

    Separating code into physical assemblies based on their logical relationships is a neat trick to help programmers decouple code. You can of course stick all the code into one assembly and everything will work the same. But separation of assemblies adds some additional constraints which are harder to violate accidentally (circular references between logical layers, inability directly to use code in assemblies which are not referenced). It’s a handy trick.

  • D. Lambert

    Absolutely spot-on. You know where a lot of this crap starts, though? Have you ever looked at some of the Enterprise architecture samples coming out of Microsoft? I’m not sure if they got jar-envy looking at J2EE projects, or got hit with a GOF book at a particularly impressionable moment, but lots of those solutions are choked with projects that serve only to obfuscate any semblance of readability.

    They’re guilty of the “requires fourteen other assemblies to run” problem, too:

  • Padgett Rowell

    I like separate assemblies. For me it’s easier to partition code both logically as well as physically in separate project. This is usually along the lines of individual projects for ‘shared core common functionality’, ‘web ui’, ‘windows ui’, ‘data access layer’, ‘entity models & business logic’ – of course it depends on the size and nature of the project. If nothing else it forces me to think ‘where do I put this bit of code?, where should it be visible?, who relies on it?, what dependencies am I introducing?’. I’m not smart enough – nor disciplined enough to have all my layers in the one project without a little tight coupling / boundry crossing creeping in. So I separate, and it works for me. At least until I learn a better way 😉

  • addy santo

    Dude! There is more than one kind of coupling. Assemblies are your unit of deployment. Which automatically also makes them your unit of versioning. Coupling in this context means “Can I DEPLOY component X without recompiling/retesting/redeploying component Y”. That concern is totally orthogonal to the ones listed in your post, yet no less important from an operational perspective.

  • Steve

    I tried to make a circular reference today and was stopped. I then had to rethink why I was wanting to do that.

    It ended up in me rethinking the solution – which ended up in a good refactor because code wasn’t where it needed to be.

    Personally, I like good namespace practices.

    Good post, but I’m not sure how MVP has anything to do with more or less assemblies created in a project?

  • Rob Conery

    I’ll jump on this… why not :).

    >>>I have known several MVP’s and MS RD’s that didn’t have a lot of depth-of-knowledge/experience but were quite popular and prominent in the community. <<<

    That would be me :). I don’t have a CS degree, didn’t know SQUAT about DI/IOC until Jeremy walked me through it 3 months ago, and as anyone in Building 42 will tell you, I can write some serious trashy code.

    Yet I was an MVP for 2 years running (ASP.NET), was awarded PayPal Developer of the Year (whatever that means) and was recruited by ScottGu to work at the Monster. I don’t consider myself a GloryHound per se, and if you look at my blog you won’t see any type of “badging” anywhere, short of my Bio (so people know who I am).

    Technical Merit is a very small part of what we do. My strengths lie elsewhere: Community, Insight, Ideas, and most of all Execution. I can put things together that frankly many others can’t – it’s just a skill I have.

    But take a look at the code I write – you’ll laugh. And I invite you to laugh because it allows me to learn – which is at the core of it all, is it not?

    Jeremy I might side with Sam on this a bit – there really is no need to further the “Alt.NET Bull##it” that has come to divide this industry. I’ve met you and know that you are a lot better than that comment.

  • Chad Myers

    @Sam: I have known several MVP’s and MS RD’s that didn’t have a lot of depth-of-knowledge/experience but were quite popular and prominent in the community.

    This leads me to believe that MVP and the RD title isn’t necessarily about technical merit.

    Having said that, many MVP’s and RD’s I know are quite experienced and knowledgeable.

  • Sam Gentile

    I agree with you my friend and agree with the strong stance. However, I am bothered by:

    > Remember that all of those awards are mostly based on visibility and successful self-promotion rather than on strict technical merit.

    All of them? None are based on merit? Do you really want or need to speak like that?

  • Craig

    “You don’t have separation of concerns because you’ve got separate assemblies, and neither does a single assembly preclude separation of concerns.”

    I think you missed their point, of course it doesn’t stop people doing things the wrong way, what it does is constantly reminding the developers of how things should be structured.

    Personally I normally have 5 assemblies for each project.
    1. Core – common classes used across multiple projects
    2. Data – basically entity classes
    3. Services – service classes
    4. Web – the web site itself
    5. Test – unit tests

  • Jeremy D. Miller

    @Casey & Derik,

    No, it doesn’t. Or at least no more than having separate namespaces within a single assembly. Even so, all you’ve done is enforce some ceremony but not the actual intent (i.e. actual, real separation of concerns).

    How many times have you worked with devs and said “we’re doing MVP” but still find a lot of logical view behavior embedded directly into the code behind? Separate assemblies are the exact same thing. You don’t have separation of concerns because you’ve got separate assemblies, and neither does a single assembly preclude separation of concerns.

  • Derik Whittaker

    I would agree with Casey in regards that separate assemblies help to keep developers honest.

  • Adron

    That makes me think… I need to cleanup my codeplex/highball project. It’s a mess right now.

    Thanks for the kick in the ass.

  • Jeremy D. Miller


    StructureMap.dll has everything related to IoC and DI. There’s another assembly called StructureMap.AutoMocking that has the auto mocker that would only be used in test scenarios. And finally, there’s StructureMap.DataAccess that is my ancient data access toolkit from the bad old days when we mucked around with ADO.Net directly.

    I do keep the testing project separate, and there’s a couple other assemblies with fake classes just to have something to point StructureMap at.

  • Andy Stopford

    Good post! I’m a little curious as how to how you have structured StructureMap, I know it’s very different to an business solution but I’m curious all the same

  • pmlarocque

    Good post, I know a lot of people who insist
    On the interace/concrete assemblies seperation.
    Everytime I ask them have you ever changed the concrete DLL
    Without the one for interface…. Answer is always No!

  • Casey

    >>>I’m very firmly in the camp that says you should only split assemblies by deployment targets, and even then, I don’t think you need to be strict about assembly separation<<<

    I think the physical separation of code can also be useful in keeping developers wary of the boundaries – logical separation is too easy to accidentally break, especially for less experienced devs – adding a reference is a dead give away that something may not be a good idea.

    That said, I rarely have a project that goes over 10 assemblies, and even then those are likely over a number of deployment targets – usually it breaks down to .Core a few .UI or .Web assemblies, perhaps an interfaces assembly, and sometimes a data assembly.

  • Mike Moore

    Couldn’t agree more. Its like you took the smartest parts of my mind, removed the Ruby infatuation, and committed them to your blog.