We are looking for a way of automatically filtering all CRUD operations by a tenant ID in Entity Framework.
The ideas we thought of were:
Using table valued user defined functions
Using stored procedures (but we don't really want to, as we're using an ORM to avoid doing so)
Some how modifying the templates used to generate the SQL to add a where clause on each statement.
Some how modifying the templates used to generate the LINQ in the controllers (we may use MVC).
Any tips?
-thanks
Alex.
Using table valued user defined functions
Table valued function are only available in .NET 4.5 Beta (and not available in code first). Using them will still not help you because you will have to use the function in every LINQ query so it is the same as using where clause.
Using stored procedures (but we don't really want to, as we're using an ORM to avoid doing so)
It can be useful for some special complex queries but generally it is not what you want.
Some how modifying the templates used to generate the SQL to add a where clause on each statement.
Too complex and on completely different level of abstraction.
Some how modifying the templates used to generate the LINQ in the controllers (we may use MVC).
Close to ideal solution. You simply need to wrap access to your entity set into some code which will look like:
public class MultiTenantAccess<T> where T : IMultitenant
{
private IDbSet<T> set;
...
public IQueryable<T> GetQuery(int tenantID)
{
return set.Where(e => e.TenantID == tenantID);
}
}
Sometimes this is core for something called Generic repository but it is really just a wrapper around EF set. You will always use GetQuery to query your data store instead of using DbSet directly.
you may also separate the tenants data into different databases
or into same database, but with different schemas? You can read more about this in an old MSDN article called "Multi-Tenant Data Architecture"
Related
I would like to override the Query Async Method with some Custom code, so I can access an external api, get some data and then use this data to query the db tables to get the results, this should support all the default sync and paging features provided by the base method. I'm using the latest 5.0 DataSync library. Old versions returned a IQueryable so this was easy to do, but now it returns an action result. Is there any solution? Could not find any docs.
e.g. I get a set of guids from api. I query the db tables with these guids and get all the matching rows and return back to client.
I know how to override the method, call external api's, get data and query the db tables, but this provides me with a custom data format not the one that the query async gives by default with paging support.
The way to accomplish this is to create a new repository, swapping out the various CRUD elements with your own implementation. You can use the EntityTableRepository as an example. You will note that the "list" operation just returns an IQueryable, so you can do what you need to do and then return the updated IQueryable.
In my ASP.NET MVC project, I use an ODBC-connection to an off-site database with a large amount of tables, from which i'll just be using a few.
I'm using Fluent Nhibernate to configure my session factory
The documentation of Fluent Nhibernate it seems to be code-first, and they drop tables when using the .ExposeConfiguration()-method, which is undesirable.
I just want to read from the tables.
My session factory looks like this:
public static void InitializeSessionFactory()
{
_sessionFactory = Fluently.Configure()
.Database(SetDialect.ConnectionString("MyConnectionString")
.Driver<NHibernate.Driver.OdbcDriver>()
.Dialect<NHibernate.Dialect.SapSQLAnywhere17Dialect>())
.Mappings(m =>
m.FluentMappings
.AddFromAssemblyOf<MyEntity>().Conventions.Add(DefaultCascade.All(), DefaultLazy.Never()))
.BuildSessionFactory();
}
Omitting .ExposeConfiguration() works with my mock-database, but the real database uses a different dialect and I get the
Column 'Reserved Word' does not belong to table ReservedWords error when I start the session factory with that dialect.
Fluent NHibernate Column Mapping with Reserved Word
The answer from Daniel in this post is the way I figured I could configure my session factory, but I don't know if that would alter or delete any data on the database itself (as it does use the .ExposeConfiguration()-method but in a different way than the Fluent Nhibernate documenatation).
How can I ensure that I never drop any tables or even write to the database in my configuration, while still being able to read from it, and bypass the reserved words-issue?
I've tried the back-tick-trick on my manually mapped entities and I still got this problem.
I am trying to use Entity Framework 4.0 for an asp .net application. As of now, it will be old style code behind files and without unit testing but in the future I may use MVP and unit testing but as of now, it is not a concern for me. I am using Database First approach. Here is a model ( I could not post image as I need reputation to post image)
Table: Application (ApplicationID, Name, Hidden)
Table: User (UserID, ApplicationID, Username, IsActive)
Table: Role (RoleID, ApplicationID, Name)
Table: UserRole (UserRoleID, RoleID, UserID)
I have been reading a lot about Entity Framework and how to use it but still could not get a very basic idea about some stuff. Where do I write a code like this for Application, User, Role, UserRole etc?
public List<Application> GetAllUnhiddenApplications()
{
List<Application> applist = null;
using (CustomAppsPortalEntities ctx = new CustomAppsPortalEntities())
{
applist = (from app in ctx.Applications
where app.Hidden == false
orderby app.Name
select app).ToList();
}
return applist;
}
I have separated Context and Entities in separate projects Project.Data and Project.Entities respectively. My question is if above code belongs to BLL (class name ApplicationBLL) or DLL (ApplicationDLL)? From past 2 days, I have been searching lots of SO questions, blogs, tutorials and different people have different approach. Here is my dilemma.
If I put the code in Data layer, then in the business layer, I have to create a "pass through" function like ApplicationBLL.GetAllUnhiddenApplications which will return ApplidationDLL.GetAllUnhiddenApplications. I have to repeat it for all the queries and basically whole BLL will eventually become "pass through" layer for DLL. Can you give me a concrete example of what Business layer will be used for in reference to above schema?
If I put the code in Business layer, then linq will exist in Business layer which eventually will be converted to SQL by Entity Framework so it is like exposing query logic to Business Layer.
Our Environment
Our environment is fast paced and want to complete this project as soon as possible with the moderately proper approach where there is a separate layer but in the future when we find time, we may refactor the code and make it really robust but it is not a concern as of now but if the time permits, we want to implement best practices right now versus refactoring code in the future.
The above code would typically be in the BL layer. Using linq in your BL layer is fine because your linq queries are still data persistence ignorant. From linq queries perspective, it's querying objects from entity framework.
What you might be missing is a "repository pattern" and "unit of work patter". The repository pattern acts as an interface to entity framework. It allows you to interact with EF objects like in-memory collections. Typically I keep all repositories in one project and reference accordingly. To give you an example, Microsoft Spain provides a n-tierd example,
http://microsoftnlayerapp.codeplex.com/
It's very over engineered, but I believe it will give you what your looking for.
Many people argue that EF IS the DLL.
Typically, I set my projects up something like this...
D ---> Presentation Layers (MVC, WCF, WinForms, etc)
A |
T V
A ---> Business Logic Layer
|
M V
O ---> Entity Layer / DLL
D
E
L
The Data Models project is really just a collection of POCO's that can be used in any of the other projects.
The Entity Layer is your EDMX file and Context.
It should be fine to access the context in the Entity/DLL layer, since .Net has abstracted everything out for you.
If you think about it, the whole reason to abstract out a DLL layer is so that you can change databases without having to change the BLL. With EF, you can change a database in 1 step and everything should still work.... as long as your schema stays the same.
Mates, I want to update a role description using my application
I don´t know what is the better way to connect to the database and run a UPDATE statement.
Would it be Entity Framework? LINQ? None of this 2 options..
Please, suggestions.
I would say that Entity Framework would be currently the best solution for you. Not only it is strongly supported by Microsoft (well Silverlight was as well) but:
If you start with it, you can use designer. It's graphical UI will guide you when generating the model (based on database) or generating the database schema when starting with model.
Read some tutorials abut it:
http://msdn.microsoft.com/en-us/data/ee712907
And later take a look how to use some more profesionla techniques as Repository pattern or unit of work
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Not Linq ..well yes linq, but linq is the querying framework where as entity framework is the object relational mapper. So Both actually. You could do this in various other ways but those two technologies work very well together from my experience.
In Visual studio you would create a new ADO.NET project template which you then hook up to your database. and then you can update the tables and do a whole bunch of stuff. Linq is build into .NET so technically you can query any objects using linq ( which makes it so much fun ) and because your entity is an object you just reference it ( first declare it ) and then play with it
FooModel foo = new FooModel(); // Entity
var fooQuery = from _ in foo.DescriptionTable // Linq query
where _.Description == SelectedDesc // table selection query
select _;
foo.Add(fooQuery); // add to database
foo.SaveChanges(); // save changes
Something like that. There is a bit more to it that would project specific but you would have to give more details.
It is most certainly worth learning both technologies and have doubt you will find them very useful. Both can get very complex but for what you need it for you just need the basics down and then you can explore from there.
I'm writing an ASP.NET MVC application using NHibernate as my ORM. I'm struggling a bit with the design though, and would like some input.
So, my question is where do I put my business/validation logic (e.g., email address requires #, password >= 8 characters, etc...)?
So, which makes the most sense:
Put it on the domain objects themselves, probably in the property setters?
Introduce a service layer above my domain layer and have validators for each domain object in there?
Maintain two sets of domain objects. One dumb set for NHibernate, and another smart set for the business logic (and some sort of adapting layer in between them).
I guess my main concern with putting all the validation on the domain objects used by NHibernate. It seems inefficient to have unnecessary validation checks every time I pull objects out of the database. To be clear, I think this is a real concern since this application will be very demanding (think millions of rows in some tables).
Update:
I removed a line with incorrect information regarding NHibernate.
To clear up a couple of misconceptions:
a) NHib does not require you to map onto properties. Using access strategies you can easily map onto fields. You can also define your own custom strategy if you prefer to use something other than properties or fields.
b) If you do map onto properties, getters and setters do not need to be public. They can be protected or even private.
Having said that, I totally agree that domain object validation makes no sense when you are retrieving an entity from the database. As a result of this, I would go with services that validate data when the user attempts to update an entity.
My current project is exactly the same as yours. Using MVC for the front end and NHibernate for persistence. Currently, my validation is at a service layer(your option 2). But while I am doing the coding I am having feelings that my code is not as clean as I wish. For example
public class EntityService
{
public void SaveEntity(Entity entity)
{
if( entity.Propter1 == something )
{
throw new InvalidDataException();
}
if( entity.Propter2 == somethingElse )
{
throw new InvalidDataException();
}
...
}
}
This makes me feel that the EntityService is a "God Class". It knows way too much about Entity class and I don't like it. To me, it's feels much better to let the Entity classes to worry about themselves. But I also understand your concern of the NHibernate performance issue. So, my suggestion is to implement the validation logic in Setters and use field for NHibernate mapping.