Home > Blogs > barry

How to partition your classes between assemblies

Posted: Thursday, June 24, 2004 3:37 PM by Barry Gervin
Filed under: , , , , ,

Eric Gunnerson has great post with some performance inspired assembly guidelines for fewer larger assemblies. Versioning and Security units of work. Good reasons.

But a non-performance reason for partitiioning into more assemblies is to stop developers from doing things like referencing your data access layer classes from a user interface layer (without going through a business object layer). If you have your classes in 3 assemblies/projects: UI, BUS and DA, where UI references BUS and BUS references DA, then it's hard for a class in UI to call a class in DA - without going out of their way to add a project reference.

Should a project always correspond to an assembly? Well that's the default but you can create intermediate assemblies called netmodules and link them together with the assembly linker (AL.exe). Net Modules are MSIL but without a manifest. You create the new assembly which links the modules together (and adds metadata) with the AL.exe.

The only problem with all of this is that you have to use the command line to compile your projects into .netmodules and link them afterwards. The net result however is that still end up satisfying Eric's performance tips with the requirement for binary partitioned UI, Business, and Data Access layers.

Comments

  • TrackBack June 25, 2004 10:15 AM

  • Barry Gervin June 25, 2004 7:34 PM

    In Whidbey there are some features that should make linking .netmodules more sane, as part of the (get this) C++ linker.

  • Barry Gervin June 28, 2004 12:41 PM

    Although I agree with your assertion that a ui layer should not reference the data layer directlly, I think this falls apart in a typical vs.net scenario, at least for me. Assume that I have a single solution containing 3 projects, foo.data, boo.biz, and foo.ui. Foo.biz maintains a project reference ( rather than a dll reference ) to the foo.data project. Likewise, foo.ui has a project reference to foo.biz. Unfortunately, vs.net will not compile foo.ui unless it too has a project reference to foo.data. At this point, it becomes a matter of developer discipline to not take advandage of this reference.

    The solution to this is to not use project references. But I don't know how many problems I've had with vs when using dll references; file locking, version mismatches, even pdb's becoming out of date. So I use project references, and I have to exercise discipline.

    trey

  • Barry Gervin June 28, 2004 1:36 PM

    That's not correct. You can absolutely have that setup with project references. In fact, Enterprise Template samples do this - and if you'd like a quick & dirty sample - send me an email.

  • Barry Gervin July 2, 2004 11:18 AM

    I use a single DLL where I make my DAL classes internal and my BO classes public. The UI can then only access the BO classes.

  • TrackBack July 2, 2004 12:36 PM

  • Barry Gervin February 16, 2005 4:44 AM

    I am realy required to do this, some help will be highly Appreciated. This is what i am required to do...

    Clients are already having some classed in an assembly, they have good documentation, now we are required to extend the functionality of these classes, we want to do it, with out changing their assembly files.

    Thanks
    Regards
    B. Ravi Shankar

  • Barry Gervin August 10, 2005 7:40 PM

    We are also using .net and want to understand class in assembly. Please do really contact and post your updates.
    Thanks,
    R.Poonkothai (Poonkothai@hotmail.com)

New Comments to this post are disabled

Recent Posts

Tag Cloud

Barry Gervin