This project is read-only.

Referencing a module's dll from another module. Good or bad?

Sep 30, 2010 at 7:30 PM


I'm writing a module that needs to know the list of available roles. At the moment I reference the Orchard.Roles\bin\Orchard.Roles.dll in my project so that I can access IRepository<RoleRecord> in the driver and then package the roles up into the view model.

Is it a bad idea to reference a module dll from another module? What's the alternative?



Sep 30, 2010 at 8:28 PM

That should be fine if you also declare the dependency in the module.txt file but you might want to use interfaces instead of concrete types as much as possible when bringing in dependencies.

Sep 30, 2010 at 8:59 PM
Edited Sep 30, 2010 at 9:00 PM

Thanks. When you say "use interfaces instead of concrete types" are you referring to IRepository<RoleRecord> or are you speaking in general terms? I can't see a way of using RoleRecord as an interface (other than object!). Here is the code that uses the repository :


public class ContentViewPermissionDriver : ContentPartDriver<ContentViewPermissionPart>
        private readonly IRepository<RoleRecord> _rolesRepository;

        public ContentViewPermissionDriver( IRepository<RoleRecord> rolesRepository)
            _rolesRepository = rolesRepository;

        protected override DriverResult Display(ContentViewPermissionPart part, string displayType)
            return base.Display(part, displayType);

        protected override DriverResult Editor( ContentViewPermissionPart part)
            // Load the full list of roles so we can present at the front end
            var oAllRoles = _rolesRepository.Table.ToList();

            if( part.RoleId == 0)
                // Default to the Anonymous role, fair assumption that it will be called "anonymous"? Can't see T("Anonymous") anywhere important
                // Also, is it a fair assumption that the anonymous role will exist?
                part.RoleId = (from role in oAllRoles where role.Name.ToLower() == "anonymous" select role.Id).SingleOrDefault();

            var oRoles = from role in oAllRoles orderby role.Name ascending select new SelectListItem()
                                                        Selected = (role.Id == part.RoleId),
                                                        Text = role.Name,
                                                        Value = role.Id.ToString()

            ContentViewPermissionViewModel oViewModel = new ContentViewPermissionViewModel()
                                                                    Roles = oRoles.ToList(),
                                                                    PermissionPart = part

            return ContentPartTemplate( oViewModel,
                                        "ContentViewPermissions.Fields").Location("primary", "3");

        protected override DriverResult Editor(ContentViewPermissionPart part, IUpdateModel updater)
            updater.TryUpdateModel(part, Prefix, null, null);
            return Editor(part);

ps: Disregard the fact that I'm using SelectListItem, I'm changing that to be check boxes so you can select multiple roles


Sep 30, 2010 at 9:35 PM

In general. One thing to understand about roles is that it is not a given that all Orchard sites will use them. So depending on the universality your module aims at, you may want to make your dependency to roles more or less rigid.

It seems like what you are building is designed on top of the idea of roles in a very fundamental way, so the hard dependency seems fine to me.

Sep 30, 2010 at 10:20 PM

Ah I see. I can make different parts then; one for roles, one for users and perhaps even one for an ip address white list which might be useful

Sep 30, 2010 at 10:29 PM

Yes, you could, although the role-based one seems the most useful?

Sep 30, 2010 at 10:35 PM

Certainly yes, roles are more useful and easier to work with, I'm just thinking ahead somebody not using roles might want to limit a content item/s to a specific user/s (one day in 2018, in error). Perhaps I think ahead too much and I should reread the Good Enough Is Fine section in REWORK!