I am using (Code First) Entity Framework 4.3 for an ASP.NET MVC project, and wanted to implement granular Permission based authorization features as provided by Rhino Security
Though it is the only such Permission based Lib available, but it's not yet been ported to EF. What can be the reason,
Such a Permission Framework is not a usual requirement in projects, so it's not so famous
Entity Framework is not so effective and so is not as ubiquitous as NHibernate
Rhino Repository is so tightly coupled with NHibernate that it's not possible to simply port it to EF
Most Important, If i really insist on using it with EF, and if you tell me it's not possible, can you please help me understand why. And if your answer is in YES, can you please help me with HOW TO DO IT
ANY OTHER IDEAS please
If I really get started implementing it using EF, would it be a futile endeavor. Any complications i would face.
As I am just a newbie both with Entity Framework and MVC, is there anything I am overlooking. So, please help me all GENIUSES out there.
Any ideas how to get started?
My opinion:
It cannot be ported directly. Rhino-Security follows concept of separating (abstracting) security from your domain model. This separation is done through IUser interface. Implementing IUser interface in your User class will be the only connection between your domain model and the security infrastructure provided by the framework. Here comes the problem. EF doesn't currently support interfaces so you cannot use an interface instead of a real entity type in the mapping and you cannot have an interface instead of a real entity type as a navigation property in your entities. Because of that Rhino-Security cannot be ported to EF without crippling its main idea - you will have to create User entity directly in ported security library and all applications will have to be dependent on that User implementation.
I'd say the third answer:
Rhino Repository is so tightly coupled with NHibernate that it's not
possible to simply port it to EF
I'm not sure about what's the reason behind that, but I'm sure it's closely bounded to NHibernate (or to Castle Active Record, that is based on NHibernate)
Related
What are the required steps to use SimpleMembership (ASP.NET MVC 4) with RavenDB (or other databases) instead of SQL Server?
I am used to override the MembershipProvider but how does it work with the new SimpleMembership?
I saw there is a SimpleMembershipProvider so I think I should override it, but I don't know if the methods are for storing data purpose only or if they should contain business/validation logic)...
What about configuration? I know the InitializeDatabaseConnection method is normally responsible for initializing the whole shebang, but I don't think I should call it if I don't use Entity Framework.
Unfortunately, I did not find a lot of resources about the new SimpleMembership except two links which have not been very useful:
http://igambin.blogspot.ca/2012/08/simplemembershipprovider-huh.html
http://blog.osbornm.com/archive/2010/07/21/using-simplemembership-with-asp.net-webpages.aspx
So here is what I found after looking at some of the the source code (MVC4).
http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/553690ac9488#src%2fWebMatrix.WebData%2fExtendedMembershipProvider.cs
SimpleMembership is an implementation of the abstract class ExtendedMembershipProvider.
The code inside SimpleMembership is mostly SQL operations and some calls to the underlying (called "previous" in the documentation) MembershipProvider.
I don't think it is of any use (in my case) to override SimpleMembership as its implementation is mostly tied to SQL Server. Instead, for what I understand, I should implement ExtendedMembershipProvider. Then, by setting this implementation in the web.config file, the WebSecurity helper would bypass SimpleMembership (default implementation) and call my implementation of the ExtendedMembershipProvider.
I don't think I will do this any soon since it looks even more complicated than before (more methods to implement)... but still doable.
However, all this said, I'm a bit disappointed that we still have to work with the MembershipProvider which, IMHO, is far (a lot of static and internal stuff) from the whole dependency injection thing that we love so much with ASP.Net MVC/WebApi.
Edit 1
This question was aked before Jon Galloway wrote this tutorial :
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
But my answer stays valid as this (taken from Jon Galloway article) resumes it:
Note that SimpleMembership still requires some flavor of SQL Server -
it won't work with MySQL, NoSQL databases, etc. You can take a look at
the code in WebMatrix.WebData.dll using a tool like ILSpy if you'd
like to see why - there are places where SQL Server specific SQL
statements are being executed, especially when creating and
initializing tables. It seems like you might be able to work with
another database if you created the tables separately, but I haven't
tried it and it's not supported at this point.
Here's my implementation for mongodb. Maybe it can help
https://github.com/malibeg/MongodbSimpleMembershipProvider#readme
SimpleMembership is not really meant to be used with the old MembershipProviders as it doesn't fullfill all of the same contracts that are assumed of normal MembershipProviders. Its mostly designed for use via the WebSecurity helper.
This link might be helpful for more info: Web Pages Tutorial
I came across this term while working on ADO.net entity framework (EF 4.0). It's hard for me to understand this term. I am aware of POCO classes and their use in creating PI model but I am not sure about a POCO proxy.
Can anyone help on this?
Are you familiar with dependency injection (DI)? POCO proxies are a form of DI:
http://blogs.msdn.com/b/adonet/archive/2009/12/22/poco-proxies-part-1.aspx
It refers to the technique used to accomplish persistence ignorance where the object is instantiated as a proxy at runtime. Castle has a proxying framework that you might want to look at to see what sort of thing you can use proxies for. Castle Dynamic Proxy
I am learning ASP.NET MVC now a days and I have found that most of the examples in ASP.NET MVC are with ORM. I don't have any issue in using ORM for my learning and personal project. But at my work we have worked only with ASP.NET web forms and we use stored procedures only. We have data access layer (simple c# classes) as interface between asp.net code behind page and stored procedures. Now if we want to use ASP.NET MVC, will it be a bad idea to do it without an ORM. As most of the MVC frameworks like rails/django have built-in ORMs, is it any harm to use our own data access layer with ASP.NET MVC. I don't want to have any database related activity like datareader, datatable in my controllers. Is there any other better solution?
If you have a DAL already built - use it! Unless you were planning on moving from your existing DAL to an OR/M anyhow you won't find it beneficial to move to an OR/M for it's own sake.
One of the beautiful things about the MVC pattern is the is encourages a separation of concerns. This means that you are reducing coupling in you application which makes your application's architecture flexible and modular. This means that if at some point you want to swap out your existing DAL for a more modern OR/M solution you can do so with minimum impact to your application.
No harm at all. ASP.NET MVC doesn't require ORMs but you should have models (that might not map to your stored procedures 1:1) of the data your views and controllers can deal with.
You can roll your own ORM if you like even. ORMs are around to make things quicker for development so that you can easily map your database data to object models that you use in your application. You can map ORMs to stored procedures as well.
I personally perfer to use stored procedures and map the results to object through my own data access layer as it gives me a lot of flexibility. This is a personal preference though and there is no right / wrong answer.
Model View Controller is a framework to help provider a clear separation of concerns between the tiers of an application. The Model can be any form you wish really. ORM is not always appropriate, if you have some other DAL in mind then use it. Direct data access with the repository pattern works well, this will help you hide the logic you do use to access your database and allow you to change it later down the track with much more ease.
I have been building web sites with ASP.NET for a while now. At first I avoided learning the intricacies of the ASP.NET Provider Model. Instead I used the canned providers where necessary, and leaned heavily on Dependency Injection frameworks for all my other needs.
Recently however, I have been writing pluggable components for ASP.NET and of course writing lots of custom provider based solutions in order to make that happen. It has become quickly apparent to me however, that a lot of initialization code is being duplicated, which is a bad thing.
So...
Are there any best practices that have emerged on how to avoid the configuration spaghetti code?
Have you built, or have any examples (base/helper classes, custom attributes, reflection) to share of abstracting the basic initialization code out so building custom providers is easier?
NOTE:
Please do not try and send me to the Provider Toolkit site. I have already exhausted that resource, which is why I am turning to the SO Community :)
I just did a rough implementation of rather basic implementation of the membership and role providers, and I don't have any code duplication at all!
I have divided everything into three projects (plus tests):
Application - asp.net mvc app. models, controllers etc.
Infrastructure - IoC and Interfaces
Infrastructure.Web - Providers
The model for User and Role implement interfaces from Infrastructure and those classes get registered to the IoC on application startup. The providers then asks the IoC to resolve the classes and does it's thing. This way I can add things to the model and user interface yet using the same providers. The one problem I've noticed, is that the web being launched by the "ASP.NET Configuration"-button can't use the providers, as the setup is being done in Application_Start and the "ASP.NET Configuration" is another web. I don't see this as a problem though.
I've been reading the book Pro ASP NET MVC Framework and I'm getting really confused with a lot of things. I've been trying to do some research but I'm finding that with so many different approaches and concepts being thrown at me, it's just making things worse.So I have a few questions:
I know MVC is supposed to split the functionality into three main things: Model -> Controller -> View. Is the MVC a different approach than the three-tier architecture? Or am I still supposed to be thinking of creating a Data Access Layer and a Business Logic Layer in my project?
What exactly are Repositories? It is what acts as my Data Access Layer? Where/How do Repositories fit into the MVC?
The book talks about using LINQ to SQL to interact with the database but yet it states that LINQ to SQL will not be supported in the future and that Microsoft is dropping it for the Entity Framework. Where does the Entity Framework fit into the MVC and how do I interact with it?
Thanks in advance for your help!
Matt
MVC is mostly a pattern for the presentation layer, and it focuses on the interaction between the view and the controller. The model can be considered to be the components of the application that are responsible for maintaining state, including persistence.
In a simple application the model might just be an LINQ-To-SQL model. In a large enterprise application the model might contain a data access layer, business layer, and a domain layer. The ASP.NET MVC does not restrict you to how the M should be implemented.
The Repository pattern is one way to implement the persistence part of the M. The ActiveRecord is another. Which pattern to choose depends on the complexity of the application, and your preferences.
Take a look at Step 3 of the NerdDinner tutorial where they create a simple repository using Linq to SQL.
Linq to SQL will not be dead. Microsoft will still improve the core and add customer requests where it makes sense but Entity Framework would be the primary focus. Take a look at this post for LINQ to SQL changes in .NET 4.0.
The EF can be used is a similar way as LINQ to SQL, but it is also more flexible so it can be used in other ways. For example EF4 will more or less support persistence of your own POCO objects in a more Domain Driven Design.
Yes, I think MVC is a different approach than "the" 3-tier architecture that I think you meant here (the architecture where you create mainly 3 projects DAL, BL, and UI). The main idea behind MVC is the separation of concerns between each of its components (Model, View and Controller). The controller is the component responsible for handling user requests, and in most cases it corporates with the "Model" component in order to display the desired view as a response to the user request. The difference between this and the traditional 3-tier architecture, is that the DAL, and the BL are grouped now and named a Model and yes you still need to create these components.
What are repositories?
Martin Fowler mentions the definition of a repository as "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects" Repositories are part of your data access layer, they don't access data by themselves, they mediate between the domain and the data mapping entities, and of course they should be placed in your Model folder/project.
Will Linq to SQL be deprecated?
NO and the same book states so, also Damien Guard ( a developer at the ADO.NET team) mentioned in one of his blog posts that Linq to SQL will be included in .NET 4.0.
How to interact with EF?
As you would with Linq to SQL. Like Linq to SQL, Entity Framework will be your mapping entities, and will reside in the Model project as well.
Hope this helps!
I guess you're a bit confused over these things, and they are confusing, so let's go over them slowly.
N-Tiered Architecture and MVC are different, but intertwined. N-Tier usually talks about separating Data Access, Business Logic and the User Interface. However, some people may argue that it is impossible to totally separate BLLs from the UI; MVC addresses that, in such a way that there is a corresponding Controller talking to your BLL, and to your View, as opposed to having your View talk directly to your BLL.
Yes, having repositories is one approach to having a DAL. There are many ways of doing this, and you should not limit yourself to what is discussed in the book.
The book only uses LINQ to SQL to demonstrate ASP.NET MVC the fastest way possible, but it is NOT the only way. Stop thinking about LINQ to SQL for a minute; ASP.NET MVC can be used whether you use an ORM like NHibernate or you use plain ADO.NET + DAL Factory or whatever -- what you'll not going to be able to use are those ASP.NET ObjectDataSources that you drag and drop with your UI.
As for Entity Framework, Brad Abrams wrote a nice guide on how to use Entity Framework with ASP.NET MVC, that should cover your last question.
HTH
Yes you still need to create data access and business logic layers yourself. Some may argue that the Controller layer IS the business logic but I personally prefer the separation between real business logic (e.g. pricing calculation) from screen business logic (e.g. event handler for the "OK" button). You will then call these from your Controller class. The controller class controls the logic for your screen and manages the translation from your data/business logic layer to the screen value.
the ASP.NET MVC framework puts no restriction on the "Model" layer, which means you can use whatever you want including NHibernate, LINQ to SQL or entity framework. I use LINQ to SQL because it's simple.
Not sure, never read that book. I just downloaded Scott Hanselman's Nerddinner project from codeplex and use that as a guide for writing ASP.NET MVC websites.