I'm just discovering ServiceStack for the first time this weekend and I find it completely amazing. As such, I'm already in the process of converting all of my projects over to it. Then I ran into a small snag.
I can't find any documentation that mentions using OrmLite starting with the database first and then mapping an existing schema into POCOs.
I've found plenty of material on code-first, but nothing on model-first.
Is there a way to use OrmLiite taking a model-first approach?
Thank you.
OrmLite is primarily a code-first ORM, but if you want to start with an existing database you would just create a POCO with properties that maps 1:1 to an existing Table and columns.
It's trivial to infer a POCO manually, but if you want some code-gen tool to help do this, OrmLite includes a couple of T4 scripts you could use instead.
Related
I am learning dotnet core and trying my hand on EntityFrameworkCore 2.2.I am trying my lab using database first approach, where I want to execute stored procedures which will contain multiple joins. Stored procedures perform read write operation. I am looking for option which is similar to EF6 in botnet 4.5 framework, where we only import stored procedure from DB and entity framework create complex type for DB result.I read multiple articles but none of these has clearly mention that whether EF core support stored procedure or not ,I want to execute mostly complex stored procedure which contains joins etc.
What I found in multiple tutorial is that everyone is importing tables in EFCore but not only complex SP. Any kind of help and suggestion will be very helpful like how to achieve it or any link to article.
I was facing the same issue and after searching it on internet i have found this resource:
Execute Stored Procedures In MVC Core Using Entity Framework Core
Now I am able to call complex type SP from EFCore, hope it will help you.
Thanks
Situation: My boss ask me if I can create an entity from a json file. Not populating one entity with values from the json, but creating a new entity with its corresponding file, table and relations.
Could anybody give me some documentation, or an example or an starting point?
Edit1:
My bad, Cerad. I have been developing web apps with symfony (with doctrine as ORM) for about 2 years now. I'm used to its workflow. But i have never considerated this request.
No, you cannot.
This is totally against the principles of how doctrine works internally. (Caches, Proxies etc)
What is even the use case?
I am switching over to Symfony for a project that I am working on but I need a little advice on how to structure the files when it comes to models and using doctrine.
I have a custom framework that I use, which in turns uses the MVC model. Pretty much all of my MYSQL database queries are stored in the models and I access them through the controller.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
I have also generated a number of Entities that correspond to my MYSQL database. My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
I'm a little unsure how to structure this.
Thanks
Pretty much all of my MYSQL database queries are stored in the models
That's bad, but I'll mention about it later.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
Queries should be done in either repositories or in some cases in services.
If your query returns entities, then it should be repository for sure.
My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
Entities should be plain PHP objects. They shouldn't depend on anything than other entities. Entities actually doesn't even know anything about database. It's pure object oriented business logic.
Again, all DB queries should be in repositories or services.
I would suggest to go through Symfony Book in first place, to get idea of how "the Symfony way" works.
Symfony is not MVC framework:
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part [...] Symfony2 is an HTTP framework; it is a Request/Response framework.
And it is great. Symfony allows to make your model as you wish without any restrictions. The Doctrine (ORM and/or DBAL) is a separate set of libraries. You can use any other library, or build your own persistence layer abstraction, or work with native SQL through PDO/MySQLi/etc.
Service is just an object that registered in the container and have some dependencies. Services can doing anything. They can represent your model, but it is not a requirement.
Organizing Your Business Logic (The Symfony Best Practices)
Doctrine ORM Best Practices
I am building a web api for my application and right now i am looking for ways to design my data access layer.
At the end, the application should be able to support a very large number of client and a very large number of queries.
I have heard about entity framework but i have two concerns with it:
I have been told by many that entity framework is not the best when it comes to performance, and performance is something that i can't afford to neglect.
I am only starting to build the application and i'm still looking for developers to join me, if i start with entity framework now, i might want/need to change an orm/library (because of the reason above or any other reason) or even a database technology in the future.
Repositories are a great way to abstract the data access layer and make it invisible to the business layer, so if one day i want to change the DAL/Database technology, i won't have to touch the business, only change the repositories.
Still, i have read a lot about how combining entity framework with the repository pattern is a bad practice.
I am really confused... and i have few questions.
Should i use entity framework? Performances is an important thing to me.
Should i combine it with repository pattern? If not, what do i do when i want to change the database technology/orm?
I have practice with using the repository pattern with native sql client (running native sql queries) but i don't have any practice with using orm's, at least not in .net
Is it really a bad thing for big application to use native sql queries and wrap them with repositories?
It is really important for me to begin writing my application in best way possible (applying all the best practices) so i won't have much struggle in the future.
Thanks,
Arik
Ad.1) Yes, Entity Framework is dead slow - BUT - when used out of the box, if the developers has deep knowledge of Entity Framework, what it does behind the scenes, how to optimize the queries - it can be as fast as your more low-lewel own implementation of data access.
Ad.2) If you want to change the ORM or the Database technology - that is not a matter whetever you use EF or not, it's a matter of the architecture you will design for the software.
Ad.1) see former Add.1, if performance is really important, I personally would go with low-level SqlDataReader, altough as I sad, it's possible to use EF in a performant way.
Ad.2) I don't see nothing bad in combining the repository pattern with EF, in small applications it may be an overhead, because the EF is basically an implementation of an repository pattern, so you would get a "double repository pattern", but it allows you to abstract away the coupling with EF
Ad.3) I don't think it's a bad way - but it depends obviously on the application.
I think that using a repository pattern is a good idea and a sort of wayout if you have some performance issues.
About Dapper the question is why Dapper is more performant than EF and NHibernate. No Lazy Load, no DML, easy mapper and so on. If you want DML (I do) and sometimes Lazy Load you could have a mixed approach. Repository Pattern + EF + Dapper.
My approach actually is Repository Pattern + EF + very few query (massive update and delete and few select - EF writes huge SQL statements also for simple queries - ). To map the select you can include Dapper (I don't), do it by hand (manually mapping or use the features inside EF - but there are some limitations - or write something generic). Usually I map it manually but I wrote also a mapper based on EF Mapping
Entity framework Code First - configure mapping for SqlQuery
I used it for few times and actually I don't use it anymore.
I see that ServiceStack.OrmLite Lite has this.
I feel like something is not sinking in with this statement from ServiceStack,
problem with Code-Gen DTO's changes breaks code, ihibits DRY forces abstraction, mutiple versions in parallel implementations
Seems to me that it means using full ORM with SS instead of a micro orm would be doing exactly this or am I way off here? I am not really sure since I auto-gen the entities but hand code the dto's.
The quote was about Code-Gen DTO's, e.g. like the development workflow WCF/SOAP encourages when you use Add Service Reference dialog or svcutil.exe to generate a client proxy.
This has nothing to do with Code-First ORMs and Data Models that OrmLite promotes.