I'm designing a blog architecture on asp.net mvc. Lets say i only have 2 entities: post and comment. do i need a controller and a repository for each one? how goes the mechanism for displaying a post with it's comments? do the post controller looks in the posts repository for the post, then asks the comment controller to retrieve all the comments connected to this post, gets them from the comments controller and passes them to the view? or maybe i should write a service which is responsible for querying both repositories and returning the results to the posts controller, which passes them to the view?
Perhaps the first thing to note is what features will your blog have and make available for its primary functions :
editing
subscription
comments
authenticating users - eg identifying the blog owner and posters.
What other ideas will yourblog have ?
Are you going to try out some new Kool ideas that you might not have seen elsewhere ? If so like what ?
The first questions that need answers are your requirements then you can start worrying about architecture and technology stacks and how to codethis or that type questions. Either way your ideas and questions are most eagerly wanted here :)
I'm not sure what ORM you are using, but I would only have a single repository for Posts. When I ask for a Post, all the comments should be attached (lazily or eagerly loaded depending on specific instance). In DDD terms I think you'd describe it as the Posts entity is the root of the 'Posts' aggregate if you want to view it that way.
I don't think there is anything wrong with having two repositories in a single controller though.
You can checkout examples such as
Kigg
Oxite
You might be interested in this other post discussing ASP.NET MVC + CSLA + DDD . It provides nice examples of projects using them together.
Related
I'm new to MVC and I've looked through a number of resources but not found any complete help so here's my understanding of what I'm trying to achieve:
I have a Model called 'Company' where each company will have a name, address, email and contact number.
I've been told this is a bit high-level as a model, something I don't really understand why..
As for my actions what should they be - add company, edit company, delete company? - Basically whatever actions are required by the user?
I don't see any problem. As always it depends on your scenario. If you are creating an app to manage companies, then your model seems ok to me. If you were a moving company, and moving companies from one place to another, maybe the Address can also be an entity in your model as it is part of your core and can contain more level of detail.
The same about the actions, add, edit, delete are good candidates. Controller receive these actions, modify the Model, and these changes are also reflected in the View.
MVC itself is a broad concept. Its meaning is more or less clear but it has been adapted to different kind of applications (i.e. web apps where it was often called Model 2).
Inside the controller Company, If you need to add company details, Inside view place your target controller as "Company" and Action as "AddCompany".
By clicking on submit button, the control directly navigates to "AddCompany" Action inside, "Company" controller.
According to that you can add company details into database.
Similar scenario for Edit/Update/Delete company.
Regards,
Pavan.G
Since your new to MVC and have not yet found any complete resource, i recommend you to watch Scott Allen`s videos on asp.net mvc 3 which start from the scratch and move up to the advanced level. It covers almost everything in MVC for beginners and should clear most of your doubts, here is the link below
http://pluralsight.com/training/courses/TableOfContents?courseName=aspdotnet-mvc3-intro&highlight=scott-allen_mvc3-building-intro!scott-allen_mvc3-building-controllers!scott-allen_mvc3-building-security!scott-allen_mvc3-building-infrastructure!scott-allen_mvc3-building-ajax!scott-allen_mvc3-building-deploy!scott-allen_mvc3-building-views!scott-allen_mvc3-building-data-ii!scott-allen_mvc3-building-tdd!scott-allen_mvc3-building-data-i-2#mvc3-building-intro
Hope This helps!
I've written a few complex MVC applications which are all role based and use .NET Membership. On my first project I used roles with structure similar to this:
Admin
Manager
Approver
I quickly discovered that wasn't very scalable, for example a customer would say "I want specific user x to have all manager privileges but not delete". I would then have to put a hack in the controller for that user.
Therefore, my second implementation led to this role structure:
CanCreate
CanDelete
CanEditAll
CanEditOwn
This approach then led to literally dozens of roles based on whether they could edit particular items globally or just their own etc. It also leads to a lot more controller actions and considerably more code - though maybe thats just the case in a complex application!
My question is, am I approaching this in the correct way, and are there any good online resources on the "correct" way to approach complex applications with loads of roles. Am I doing this correctly?
Indeed it's very interesting topic and I found myself struggling with the same problems as you do.
I read Derick Baileys interesting blog about that "Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks" : http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
but had not time to experminet it myself.
A year on from this question I handle things a different way across projects. I'm now sticking to the classic roles of:
View
Edit
Delete
Add
BUT the action methods themselves return data like this:
var order = or.MyVisibleOrders().FirstOrDefault(x => x.Id == Id);
The logic for what is viewable and what is not is then handled by roles in the repository. The database will essentially never be queried for the restricted items in the first place.
Basic stuff but felt I should follow up on myself.
I'm still just getting into MVC, and for my first real project I plan on creating a blog. This will be extremely basic (at least at first). Everything I need is going to be on the same page. Here are the initial features I am shooting for:
User should be able to log in, but not register (I will be the only one able to post, and I added myself directly to the DB.
Blog posts should be listed in descending order with a Title, a post date, and the body. No comments required for now.
The bottom of the page will always have an area to make a new post, assuming you're logged in.
Since I'm still new to the MVC structure, I'd like some advice on how it should be organized.
For my models, I figured I should have a post repository and a BlogPost class for the post data which can be used for both the posting and retrieving. I would also need a class for the user.
When it comes to controllers I'm a bit less confident. Should I have a different controller for every type of action? For example, posting should have a controller, retrieving should have a controller, logging in should have a controller, etc?
As for the views, since I really only need a single page, should I only have a single view and have that view output the appropriate content from my controllers?
Just let me know if I'm on the right track, I suppose. If my thought process is way off, please tell me. I've just started working my way through Steven Sanderson's MVC 2 book, but I feel like I need to go out on my own and play between my reading sessions.
Thanks.
Controllers should be grouped by functionality. You could also have a controller per resource (REST). You could have an AuthenticationController which handles authentication and PostsController which will handle the posts retrieval and adding a new post. As far as the views are concerned assuming you will have a single page that will list posts and add new posts you could have a single view but maybe with multiple partial views/editor/display templates.
Actually im doing a home page that only have an action called Index() that returns the view Index.ascx.
This index page will be composed by lastest news and lastest registered users, i think that create two partial views is the best idea (this way i could use it in other views).
for other hand i have a data access class that calls to database for get stuff (get last news, get last users, etc...)
My question is simple, should i call to the this data access class in the Index() action of my HomeController, and add to the ViewData the data obtained?
I think that this index() action shouldnt be the responsable of passing this data to the partial views, right?
Could you give me a hand?
im messing too much? ;-)
Thanks in advance.
Best Regards.
Jose
You should use the Repository pattern to encapsulate the data access and separate it from the Logic / UI. The controller of the Index() method should access the repository and receive data from there.
A great tutorial to learn ASP.NET MVC is this one: NerdDinner. There, the usage of a repository class is explained, too.
[Update] An even better tutorial is the official ASP.NET MVC Music Store Step-by-Step Tutorial.
By using a repository you access other advantages such as the possibility of Dependency Injection which is a great enhancement for testability ...
I suggest you use Action methods to control only to decide display content and not what it displays.
I would say encapsulate the Data Access logic in one more layer , so that it is loosely coupled from the controller actions.
This results in having 'Thinner actions and Coarser Models' . You might want to use a repository pattern as described in Scotts blog or follow Domain Driven Design which illustrates the responsibility of each of the layers.
Hope this helps.
Thanks ,
Vijay
You're spot on in thinking it's ideal to separate the news and user list out to partial views as you can reuse them in other parts.
It's also ideal to separate the data functions for these out too into a separate class often call repository class. So you might have a News repository class which would have a GetNews function on there. You can then call that function from inside your news list. Anywhere else you want to get those lists you can just call that function and you're not writing the same data retrieval code again.
About a week ago I saw a blog post describing how you could write a set of shared Views in the Views/Shared folder that could be used by all your Models. The post also explained how to decorate the Model properties with validation rules and messages. There was information about the new Model Binding improvements. The examples take advantage of new functionality in the preview release of ASP.Net MVC 2.
For the life of me, I can't find the blog post or other information on how to create the shared views.
Can anyone offer a pointer to the post?
Ask and you shall receive.
I've been playing with this quite a bit in the past few days. In addition to generic, dynamic display of editors, details, etc., I've also implemented generic, dynamic modification of data. Essentially, Phil's sample project covers the GET side of things, and I've implemented the POST. I'm also looking into dynamically generating JavaScript in order to have a dynamic list using jqGrid. Stay tuned to my blog if you're interested in this sort of thing.