I am looking for tutorial or sample for Dapper using token based authentication in web api 2. I appreciate if anyone can suggest where to start, I have found tutorial in http://www.c-sharpcorner.com/UploadFile/ff2f08/token-based-authentication-using-Asp-Net-web-api-owin-and-i/ but the sample is using EF and I havent tried using EF, but dapper also I am using MySQL for my database. Thanks in advance and good day.
Dapper is a very different tool to EF (which is the DbContext described in your step 3 / step 4). It simply will not be compatible with those steps, and isn't designed to be used with those steps.
But here's the thing: dapper is just a tool. EF is just a tool. It is ok to use more than one tool. If it suits your purposes, then use EF to do one set of jobs (for example, to help you use a particular library that is designed with that in mind), and use another tool (such as dapper) elsewhere in the same project. That's OK. No one will mind.
If you really really don't want to use EF at all, then you'll need to find out everything that the library needs to support what you are doing, and implement it manually. If the library is designed around IQueryable<T> etc, then this may be very difficult.
Related
I'm working on an IT School project, so I'm gonna explain what I'm doing. I am designing a Telemarketing Campaign Creator. The MySQL Schema and database are correctly created but I have several problems and doubts.
I'm using Zend 2 Skeleton as my start point and I'm friendly with MVC programming method, so my doubt is how to start for implementing the models from my MySQL DB for my project.
Is there a methos to generate automatically the models?
Thanks for all! =D
P.S: I'm programming under Zend Studio 10.
If you're starting from scratch with Doctrine2, I would strongly advise you to come at it the other way around: Define your entities in doctrine, and use the doctrine CLI to generate and update your MySQL schema.
Remember, with Doctrine2, your Entities (which are 'just plain php objects') are first-class citizens. Database schema is just an implementation detail.
Once you get the hang of this workflow, it's incredibly productive. When the need arises, you can pull in the doctrine migrations library, and use it to easily manage schema changes over time.
I am trying to use dapper-dot-net to speed up some area of my asp.net mvc application. I am using EF5 Code first also.
Since dapper-dot-net is just some extensions for IDbConnection, can i just use
DbContext.Database.Connection
to use dapper-dot-net? I test it is working. However, i am not sure this is the right way to use it? Especially, when I use that way, will Entity Framework still has some impact that could hurt the performance?
Using Dapper could be a significant performance improvement in certain scenarios.
You can share the EF connection with Dapper. However (although unlikely to be a problem) you should be mindful of concurrency issues (e.g. due to attempts to associate multiple data readers with the same connection).
If you do run into such issues, you have the option of giving a new connection to Dapper using the connection string (DbContext.Database.Connection.ConnectionString), instead of sharing the connection.
Yes, you can use it that way. Since Dapper is just working on extension methods, you can use it for the performance-sensitive areas of your code. And you can continue to use EF for other areas of your code. The queries that you have that are still using EF will not be as fast - but at least the queries using Dapper will be faster.
I think you have to rethink about the question. Increasing performance via changing the ORM is not a good technique. It is correct that dapper is faster and lighter than EF but this does not mean that to increase the speed of your application its better to use the dapper. EF is powerful enough to handle the whole data layer if you suffer from performance you have to introduce new feature like caching or no sql db.
you have to see that changing from EF to dapper how much will save time for you ? and how much speed can caching bring to your application.
and adding dapper has other expenses: how would you manage the transaction while you have to point of save and update how you are going to solve the roll back situation, what about the Unit of Work and Repository pattern.
These are the factor that you have to examine before deciding to go for Dapper.
I learned to love how LINQ enables set operations on collections. I'm not saying that I plan to shun traditional RDMBS, because I do need it for reporting. There are NoSQL alternatives out there, but they seem to all need to fire up a separate service.
What I looking for is something local where a DLL can create a database and perform CRUD on it. As mentioned, I'm not going to report out of this, just internal data store. The main application that will be using it is in C#.
I'm hoping that someone can give me a lead. If not, if there is anyone willing, we can start a open-source project for it. I'm not interested in commercial products.
Thanks,
You can run RavenDB in embedded mode inside your .NET application - no need for external services or anything.
And RavenDB supports Linq....
I've built a site in MVC3 using EF 4.0 using the Repository pattern. Everything was going good but I'm starting to run into a lot of "The relationship between the two objects cannot be defined because they are attached to different ObjectContext objects" errors. It seems that my repository layer is getting the contexts all mixed up, so I figured it might just be easier to start a new EF4.1 project.
At first I looked into Repository Pattern + Unit of Work, but came across some threads saying that this isn't needed for EF4.1. I came across this thread saying "DbContext is implementation of unit of work pattern and IDbSet is implementation of repository pattern.". I figured maybe then I could just use that. Upon further inspection though it seems that DbContext uses the Code First approach, which as far as I can tell will drop and create the database again if the POCOs change. I need to keep the data in my database, so as far as I can tell that option is out.
My head is spinning right now with EF options. Is the Repository pattern needed with EF4.1? Is DbContext meant for working on databases that are already full of data? Is there a better way of managing the entity contexts that don't involve these?
Any push in the right direction would be great =/
A few comments. For details I recommend to do some basic research using a search engine.
...I'm starting to run into a lot of "The relationship between the two
objects cannot be defined because they are attached to different
ObjectContext objects" errors. It seems that my repository layer is
getting the contexts all mixed up, so I figured it might just be
easier to start a new EF4.1 project.
If you have this error you did something wrong. EF 4.1 won't protect you to do the same mistake again because you also cannot change relationships between objects that are attached to different DbContexts. You just have to analyze and debug your code and find the source of the problem.
...this thread saying "DbContext is implementation of unit of work
pattern and IDbSet is implementation of repository pattern.". I
figured maybe then I could just use that...
ObjectContext and ObjectSet<T> is an implementation of those patterns as well. This is no reason to change the version of Entity Framework.
Upon further inspection though it seems that DbContext uses the Code
First approach...
You can also use Database First and Model First approach with DbContext.
...which as far as I can tell will drop and create the database again
if the POCOs change. I need to keep the data in my database, so as far
as I can tell that option is out.
You can turn that feature off. Also, EF 4.3 has a migration feature which helps to update and evolve an existing database schema.
Is the Repository pattern needed with EF4.1?
No. It's also not needed for ObjectContext. To be precise, it's not needed that you write your own (abstract) repository of top of EF, because EF is already an implementation of that pattern.
Is DbContext meant for working on databases that are already full of
data?
Yes. The additional feature to create a database from code (Code-First) is mainly a productivity tool for the development phase of your application which is supposed to be disabled in production.
I don't really plan on using active record or any of the built in database constructs native to CodeIgniter for database access. I have Oracle, SQL Server, and others. I want to use PHP PDO (unless anyone thinks that's bad) because of the universal aspect of it.
I mainly want CI because of some of the built in libraries and MVC. I also like that it is small and easy to work with.
2.x if it matters.
I did see other questions but none exactly about databases.
Thanks.
edit: It's not that I don't think CI and PHP can take it with large websites. This is solely about using multiple databases of varying companies. I have mostly seen MySQL used with it. I know I can use other databases but again, I don't know if it is more trouble than worth or what.
MySQL is the default just because of how widely-adopted it is, especially in the PHP world. Almost everyone has a *AMP stack to work on so it ends up being the main driver used in almost every example out there.
If you're not planning on using the database class, then it really doesn't matter what type of database you are using, just don't load the class. You can still use routing, helpers, libraries, and other CI features.
So yes, I do think it is suitable for your purposes.
CodeIgniter was built with the idea of being the framework closest to native PHP that doesn't tell you what to do. The entire framework is modular and you are not required to use any single component.
Yes, it is absolutely suited to what you are doing. You can plug and play whatever DB driver you want and CI will not complain one bit.
I think CI is more suited for this role than any other of the 'big' frameworks.