I am building an MVC (Microsoft) application that uses repository to access data.
I have a requirement where based on user role, you may or may not have access to certain pieces of data, or certain rows within a data table that contain flags or values.
Basically I need to customize the data coming back from the repository based on role.
What do you suggest?
1) Create a 'public' and a 'private' concrete repository from the same IRepository and customize the logic in each, then intantiate at the controller based on role membership.
2) Create private methods inside my one repository and choose the correct one based on the public/private role membership.
3) Other?
Thanks.
Other
Make it data driven, or you will end up in a word of pain.
Roles tend to grow
Update
Create table that maps roles to properties use flags if there's more to property-role relationship than can/cannot, then create Factory that can produce objects based on input from that table, then define interface, and create control mechanism for handling these role based properties.
Yeah now it sounds somewhat complicated. :)
A repository by definition does CRUD, there should not be logic in it (from what I know).
The queries that hit your repository should deal with not retrieving X information since your user Y doesn't have the right to see it.
If you keep business logic out of your repository you will find it much easier to maintain.
Edit : It's just an opinion, I'm far from an all-knowing mighty Jon Skeet ;)
Related
I'm working on a small project that is using MVC 5. I have a Projects/Details page which displays information of a given project. Each project have multiple members and there can be 3 member types. These types have different information and functions available on the page. My current temporary solution is basic, in my View I have an if statement to check the type of the logged in user and show a partial view accordingly. To me this solution feels kind of "hacky", I'm sure there's a better way. So my question is: how would you go about implementing such functionality?
Thanks.
There are three ways in which you may want to approach this.
1) Even if you think your proposed solution is "hacky", it is actually not a bad idea. I personally did it in a project. I created partial views depending on the roles a user had; however, you'd be adding extra business logic to the view. Try experimenting with it, and see how it performs when deployed. This should be your first try since it's actually your idea, and by experimenting you'll learn considerably.
2) Have you tried checking in the controller for a user's roles, and depending on that role returning a specific view? In this case, the business logic will remain in the controller, and it is considered a good practice.
3) Even if I don't know whether you are using an ORM (Entity Framework) or connecting directly to a SQL database, try retrieving a member's roles using a stored procedure and checking for its roles in a DB handler class.
As you may see, there are three options to check for a member's roles.
Finally, I recommend you reading about claims/roles-based authorization. It may help you in future projects:
https://www.c-sharpcorner.com/article/Asp-Net-mvc5-role-base-accessibility/
I am using ASP.NET MVC to develop a website for order entry. The orders are not just about buying a product but about building a new customized product given the available product parts.
With MVC is kind of intuitive to restrict permissions to actions. For example, only admins can create new product parts (e.g., call the action CreateNewWheel). Users on the other hand can call the action BindExistingWheelToMyNewCar.
HOWEVER, is there a design pattern to restrict access to content? I need to give permission to content itself that is going to be displayed, not actions that can be executed.
I guess that I can always start creating database relationships here and there based on user roles. But my question is: Is there an existing design pattern that covers this scenario and that I can use as a guide? I want to get as complex as permit, restrict, and inherit permissions that will allow to define which product parts will be presented to end users.
Any hint will be useful.
Thanks,
I'm looking at adding functionality to a DDD project but I'm unsure of the best way to fit it in.
The needed functionality is tagging and user groups manipulation.
As many things will be taggable (users, journals, documents etc) it seems anti-DRY to recreate that functionality in each AR. Would it be sensible to have a Tag Repository which maintains a central tag table, then have various many-to-many tables for the different tagging types needed (i.e. associating tags to userId, journalId etc) or perhaps even a single many-to-many table which records the relationship type. If so, would the domain object have to be modified to hold the link to the tags?
The group functionality is similar. There is a need to allow users to create user groups, and then assign groups to non-public entities (journals, documents etc) to give them view access.
What would be the best way to add this new functionality to the project?
Design separate bounded contexts for tagging and the group functionality.
The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.".
By separating, you promote the unambiguous and authoritative representations of the knowledge DRY is all about.
Title is not the best but I will do my best to explain what I mean.
When you create ASP.NET MVC application and you need to fetch data about user profile (just an example) where do you place these files and how do you construct these queries (Lets assume that I'll use some kind of ORM like Linq 2 SQL and that I'll use ninject)
once again lets assume that will have interface which defines all details about user profile (name, surname, password...) now I wonder do you create methods for fetching data like (GetName, GetSurname...) and you define way you fetch data inside UserProfile class which inherits this interface we have defined or you define one method for getting all user account and then preform query inside controller.
If you have any useful links about designing(?) MVC application please post it
see my answer about how to properly layer an ASP.NET MVC application:
MVC3 and Entity Framework
such answer is in fact generic, subjective and does not apply only to web applications, same approach can be used for windows clients and other architectures.
There is nothing magic and actually this is subjective and also depends on experience, the general idea is to minimize or actually avoid dependencies between all layers above DAL and the ORM (if any) used to fetch/map data.
I have a design where I want to be able to assign one or more command objects to an entity, which will then use these commands as part of its workflow. Something like assigning add-on features to a user's account, for argument's sake.
I understand the Command pattern and how this fits, but my question is one of persistence. If I have a list of commands, where each user account can have its own list of commands, and let's assume for argument's sake that the only thing important about the command is its system Type, and/or they all have the same properties. What's the best way to persist that when it comes time to implement my data layer?
I was considering doing it as a many to many relationship between the accounts table and the commands/features table, where the latter table follows a TPH strategy (i.e. all commands persisted in the same table). That seems to be the most clean way of doing it, but I wanted to see if anyone else follows a different strategy?
Do you instead make it a 1: many relationship, where any two accounts that have the same feature added have a different instance of that feature? Or is there a better way that I'm not thinking of at all?
Many-to-many with TPH looks ok to me.
Though I wonder your design decision to attach commands to different users, seems like you are trying to use them for authorization | permission purposes, instead of implementing normal authorization system using Role Based Security, or ACL. If it as the case then I would probably use role based security at internal level and for UI commands that are created dynamically based on internal security rather then statically stored in DB.