I am trying to build a simple db application. I learned EF code first approach and liked it. However I don't want to deal with interface design. Lightswitch seems to be right tool to create my CRUD screens easily. What I understand is I can easily develop my application logic, db structure and test it using lightswitch. However I am not sure about how to use lightswitch with EF code first approach. Can you suggest a way to solve my problem?
Related
[Pre]
I have to say that I'm dummy newbie who is trying to get together important puzzles with such crucial details as DDD, TDD, MVVM, and EFCore. I have an about 10 years of windows form develop experience in complete wrong manner, and after I'm joined to Plurasight I'm understood that I'm just lost my last 10 years, and this is really sad :).
[Problem description]
I have an App that i want to re-write from scratch by using latest and greatest technics that've learned for the last 6 month on Pluralsight, but the problem is that these new knowledge’s is stopping me, because simply I'm afraid that I'll do it wrong again...(that is stupid I know, but it is what it is).
So back to my questions, I have a big problem domain, and pretty well documented business logic, which i have to turn in to the code. I'm understand that my start point is design data layer, for these purposes I want to use Entity framework core (I saw Julie Lerman's course on Pluralsight and I think's she is amazing and inspires me to use EFCore as ORM for my app). But at the same time leakage of experience produces more questions than what I’ve learned with Pluralsight, and I will try to write them all(please don’t judge me too hard)
It is looks like that I will need 2 or even more data model projects in my solution, and here is why I have multiple document set types, each of the type contain more than one reference books used to generate unique file names and data sheets. But it looks weird to me have 3 Data model projects such as MyApp.PackType1.DataModel, MyApp.PackType2.DataModel, and each of them will be preinstalled with the EFCore, and each of them will generates its own database based on Data Context defined by EF. Isn’t it very redundant or this is correct way?
I don’t understand how to join these multiple Data Models projects, including Shared Kernel into the one nice model
I don’t understand what is the best way to design my data classes? Should they be just POCO’s or I can design them as nice looking classes with the private var’s and public properties? What are the best practices in here?
Also I don’t understand what is the best practice to use a MVVM pattern on top of that, and is it applicable at all to use MVVM in this case?
Should I keep my Tests in separate projects like MyApp.PackType1.DataModel.Tests, or keep them in same project?
Best regards,
Maks!
P.S.
Apologize for unclear definitions and questions, English isn't my native language.
It's very complicated to answer your question because you have asked for a lot of details, but I going to provide a brief answer and I hope it will be helpful.
You can have only one model for your entities (DDD) and create sub model from this model in your end level projects (Web API or UI)
Read point #1
You have to create an Entity Layer project that represents your database and then you can create DTO's for specific scenarios
From my point of view, use Angular but you can use another UI framework such as React or VueJs, but I prefer to use Angular to build UI interfaces and consume .NET Core Web API from client
Create unit tests and integration tests for you Web API projects and as additional feature you can use Db in memory provider for tests
May be this guide is useful: https://www.codeproject.com/Articles/1160586/Entity-Framework-Core-for-Enterprise
Regards
Hm, multiple DbContexts (models) usually come about when you have distinct databases you are using. General rule is one Context = one Database. Exceptions can occur when there are a lot of tables that can be grouped functionally, but there are downsides to that approach.
A DbContext is a repository pattern but for individual tables. Using a Unit of Work pattern and layering with a custom repository provider would allow you to make it "appear" as a single database, hiding the complexity from the front-end.
Your entity descriptions are usually created as straight POCO. You can get creative with different DTOs
In a nutshell, an MVVM pattern goes like this:
Request from UI to a controller
Controller possibly issues multiple calls to Data Layer to gather data
Assemble data in a single ViewModel (everything the page needs)
Return to UI
The beauty of the approach is single roundtrip (request/response) to the UI
Separate Project in my opinion. There are techniques to spoof the database connection using EF so you are not using "live" data.
That CodeProject article will come in handy.
I'm going to start an new application with MVC Web API. Api should communicate with DB. Data base is not yet designed, but this DB will communicate with more then one application. So which way I have to choose.
Code first is a good chooice for you, for the following reasons:
Code first is prefered by programmers
Good support in EF Core
more flexibility
You can use bounded context to communicate with other databases
Other info:
The image is copyied from:
http://www.entityframeworktutorial.net/choosing-development-approach-with-entity-framework.aspx
I am new to entity framework and MVC, and trying to understand what constitutes a good design approach for a new application.
There are several ways of using Entity Framework. However, for my project, the best looking option is DB First. I've played around with an EDMX file, and I have got as far as using the DbContext code generator to create my wrapper classes.
I plan on using the repository and unit-of-work patterns, and using ninject for DI.
However, it does not seem "proper", from a SoC point of view, that whilst my respository will hide the implementation of the data store (EF) from my code, the model classes themselves are very much EF flavoured.
It seems that using EDMX-based approaches to EF blur the separation of concerns. Only POCO support seems to allow a true separation, but POCO has some other limitations that I don't like.
Am I missing something, or does using EDMX have this drawback?
Are people using an auto mapper to convert between the entity model and another, clean, SoCced model?
thanks
Tian
I don't have a strong opinion on the Separation Of Concerns question, but I have used both the standard ADO.Net version of EF and POCO and it is not difficult at all to customise the output of the the T4 code generation script for POCO to address any concerns you have about the structure of the objects created. That sounds like it would probably be a good starting point for what you are looking to do.
Once you know you are looking for T4 templates there are quite a few tutorials and a lot of helpful SO questions that can give you an idea of what you need to do.
I used Entity framework with a database having around 50 tables and it worked just fine.
But just to see what happens with a larger database in terms of number of tables/entities i tried to implement the Entity Framework to a database that had around 100+ tables.
Once i selected all the tables and clicked on the Finish Button on the Entity Framework Wizard its just hanged my VS 2010 so i could not get any results.
My Questions are as below;
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
4.How will these different DataContext interact with each other?
5.Is there any recommended no of tables that should be used while working with Entity Framework?
#Will is correct that the limitation you're seeing is in the designer, but it's not the only one, so Code-First doesn't necessarily fix the problem.
If the designer seems slow, it's inconvenient, but not the end of the world. Runtime performance considerations are another thing altogether. For performance-critical tasks and tuning, you'll want to understand the whole pipeline.
View generation, e.g., takes time. You can move this to compile time with manual work.
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
I certainly wouldn't let it stop you.
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
That's certainly a good approach for many applications.
4.How will these different DataContext interact with each other?
Mostly not. A single, giant data model is often a bad idea due to service coupling. However, you can selectively couple them by sharing portions of the models with includes in EDMX or classes in code-first.
5.Is there any recommended no of tables that should be used while working with Entity Framework?
One way is to use smaller models, as you've suggested. Another way is to work around the runtime performance issues which sometimes come with larger models (see the links I give above). Like any potential performance "problem", write correct code first, then profile and fix the slow parts. Usually, query tuning is more important than model size anyway.
EF, probably yes. The toolset in Visual Studio? Not so much, apparently. For a database this big, you might want to do Code First.
I think EF itself have't performance limitations for count of tables, but have for count of records in particular table. You have to do manual object-db relation (i.e. manual write classes for tables and corresponding attributes) for go away from design problems in VS10.
It's clear approach in Hibernate, but in EF probably not.
Entity Framework is the best way to develop database applications.
I used to develop my applications using LINQ to SQL but since Microsoft is not going to support it in future, it recommends to use Entity Framework.
By the way, Entity Framework 4 in .NET 4 has much better performance than previous versions.
I'm currently developing an enterprise application using Entity Framework and it supports all my needs.
I suggest to use Entity Framework.
I currently use the Entity Framework designer to generate my persistance objects and I also user POCO view models for the ASp.NET MVC view.
I've read and listened to a lot of people talking about the good support for POCO's in EF4 as well as POCO's in general but I can't seem to work out what advantage, if any I'll get from using them.
In our application, we WILL be using SQL Server so it's not like we need so separate out for different databases.
Why would I want to use POCO's as opposed to the designer generated classes?
POCO offers better extensibility/reuse of your Domain Model as you're not tied to any specific ORM framework.
Answered here :What are the 'big' advantages to have Poco with ORM?
Easier to unit test
I find when you have many entities (100+) using the designer is painful and POCO objects are easy to create and maintain.
With POCO's you can "Code First"
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
+1 for with POCOS you can code first. In fact you can create and test your entire application before you even write your first line of data access code. This is how it should be, it's a perfect application of the SRP. Your domain object should not know or care how they are being persisted.