How to handle spatial data with abp.io framework (SQLServer and EF Core)? Any recommendations?
I guess one can have NetTopologySuite in the Domain project, but it does not feel DDD correct to do so.
Please tell me if you have any experiences with this combination.
Abp Framework project are just a .Net Project. you can use the NetTopologySuite like you normally use in any other project. if you don't want DDD then just create a single layer project. single layer project removes all the DDD requirements.
Here is the more info about single layer project: https://docs.abp.io/en/abp/latest/Tutorials/Todo/Single-Layer/Index?UI=MVC&DB=EF
Related
I have created a new application, using the SPA templare of .netcore, to this solution i want to add another project to handle the database connection(DAL).
When i am adding ASP.net core Web Application to this solution, i then want to add to id an ADO.net entityframework template, but in the data section, it dont appear:
So I end-up adding a class Library(.net framework)
and to it i can add an ADO.net Entity Data Model
So now in the solution, i have 2 projects, 1 is .net core 2.1 for the API's, models and views(by angular).
The second project is a .net framework 4.6.1, class library project.
My question is, is it suppose to be like that?
is it a good thing to mix different frameworks
Please see this article regarding what each framework is, and what each is specifically designed for.
https://learn.microsoft.com/en-us/dotnet/standard/frameworks
In a nutshell, your requirements drive which framework you choose.
I would recommend sticking with EF Core (just my personal opinion, take it or leave it) The EF Core method of database first is only recommended if you require a 1 time migration from a source database. Microsoft Doc
If you need to CONTINUE working with an entity model past the first migration, it would be in your best interest to use Entity Framework 6, on a .NET Framework library like you have. But that doesn't stop you from using EF Core as your OR/M, because you can indeed have .NET Core reference .NET Framework.
I am new to MVC and EF.
I use to follow 3 tier architecture before with asp.net with BO,BLL,DAL,UI(asp.net webform).
I want to follow same with MVC4 in UI layer, in replace of webform.
I have generated my entity from database in DAL but now I am confused what is the use of BO layer now ?
Because all my entity are in DAL layer itself.
Also I will create Viewmodel classes in model folder so don't know how the flow will go now.
I am confused about the architecture now, please suggest if I am doing it correct or not, or is there any different approach I have to take for best practice,
PS: I don't wanna use single layer in my project. I think EF save our time by creating BO classes and enable sp used as functions and we don't have to use Ado.net repetitive code again and again.
As finally no help I got from 29 views counts, So I opted to create BO again from my project, DAL consist of E.F and UI have Viewmodels and ViewmodalList.
In your case, DAL should .edmx files. And if you want to use repository patterns you can add there.
In Business Logic layer, you will add your services. Where you are actually performing database operations.
You can declare another layer for interfaces as well. Or you can use Business logic layer for it.
I am using Entity Framework 6 database-first. I am converting the project to implement the onion architecture to move towards better separation of concerns. I have read many articles and watched many videos but having some issues deciding on my solution structure.
I have 4 projects: Core, Infrastructure, Web & Tests.
From what I've learned, the .edmx file should be placed under my "Infrastructure" folder. However, I have also read about using the Repository and Unit of Work patterns to assist with EF decoupling and using Dependency Injection.
With this being said:
Will I have to create Repository Interfaces under CORE for ALL entities in my model? If so, how would one maintain this on a huge database? I have looked into automapper but found issues with it presenting IEnumererables vs. IQueryables but there is an extension available it has to hlep with this. I can try this route deeper but want to hear back first.
As an alternative, should I leave my edmx in Infrastructure and move the .tt T4 files for my entities to CORE? Does this present any tight coupling or a good solution?
Would a generic Repository interface work well with the suggestion you provide? Or maybe EF6 already resolves the Repository and UoW patterns issue?
Thank you for looking at my question and please present any alternative responses as well.
I found a similar post here that was not answered:
EF6 and Onion architecture - database first and without Repository pattern
Database first doesn't completely rule out Onion architecture (aka Ports and Adapters or Hexagonal Architecture, so you if you see references to those they're the same thing), but it's certainly more difficult. Onion Architecture and the separation of concerns it allows fit very nicely with a domain-driven design (I think you mentioned on twitter you'd already seen some of my videos on this subject on Pluralsight).
You should definitely avoid putting the EDMX in the Core or Web projects - Infrastructure is the right location for that. At that point, with database-first, you're going to have EF entities in Infrastructure. You want your business objects/domain entities to live in Core, though. At that point you basically have two options if you want to continue down this path:
1) Switch from database first to code first (perhaps using a tool) so that you can have POCO entities in Core.
2) Map back and forth between your Infrastructure entities and your Core objects, perhaps using something like AutoMapper. Before EF supported POCO entities this was the approach I followed when using it, and I would write repositories that only dealt with Core objects but internally would map to EF-specific entities.
As to your questions about Repositories and Units of Work, there's been a lot written about this already, on SO and elsewhere. You can certainly use a generic repository implementation to allow for easy CRUD access to a large set of entities, and it sounds like that may be a quick way for you to move forward in your scenario. However, my general recommendation is to avoid generic repositories as your go-to means of accessing your business objects, and instead use Aggregates (see DDD or my DDD course w/Julie Lerman on Pluralsight) with one concrete repository per Aggregate Root. You can separate out complex business entities from CRUD operations, too, and only follow the Aggregate approach where it is warranted. The benefit you get from this approach is that you're constraining how the objects are accessed, and getting similar benefits to a Facade over your (large) set of database entities.
Don't feel like you can only have one dbcontext per application. It sounds like you are evolving this design over time, not starting with a green field application. To that end, you could keep your .edmx file and perhaps a generic repository for CRUD purposes, but then create a new code first dbcontext for a specific set of operations that warrant POCO entities, separation of concerns, increased testability, etc. Over time, you can shift the bulk of the essential code to use this, while still keeping the existing dbcontext so you don't lose and current functionality.
I am using entity framework 6.1 in my DDD project. Code first works out very well if you want to do Onion Architecture.
In my project we have completely isolated Repository from the Domain Model. Application Service is what uses repository to load aggregates from and persist aggregates to the database. Hence, there is no repository interfaces in the domain (core).
Second option of using T4 to generate POCO in a separate assembly is a good idea. Please remember that your domain model (core) should be persistence-ignorant.
While generic repository are good for enforcing aggregate-level operations, I prefer using specific repository more, simply because not every Aggregate is going to need all of those generic repository operations.
http://codingcraft.wordpress.com/
I would like to ask you how can I implement DB First model in ASP.NET Identity Scheme. When I create a WebAPI project with individual user authentication I can see code-first model with some implementation in it. I am trying to solve this and I was searching for some solution but i didnt found it. Do you know about any good tutorials or just the solution? Thanks
Models need not be present always inside Model folder of web-api project.
They can be from other dlls as well.
I would suggest you to create a new project for your Data Access Layer, and add the EF databasefirst dbml to that project. Later refer it in your web-api project to use it.
I am building an application using entity framework. I am using the T4 template to generate self tracking entities.
Currently, I am thinking of creating the entity framework code in a separate project. In this same project, I would have partial classes with additional methods for the entities.
I am thinking of creating a separate project for a service layer (WCF) with methods for the upper/presentation tier. The WCF layer will reference the entity framework project. The methods in the WCF layer will return the entities or accept the entities as the parameters.
I am thinkg of creating a third project for the presentation layer (ASP.net), this will make calls to the WCF service but will also need to reference the entities as the WCF methods take these types as the parameters/return types.
In short, i want to use the STE entities generated by the T4 template as a DTO to be used in all layers.
I was originally thinking of creating a business logic layer that maps to each entities. Example: If i have a customer class, the Business Layer would have a CustomerBLL class and then methods in the customerBLL will be used by the service layer. I was also trying to create a DTO in this business layer. I however found that this approach is very time consuming and i do not see a major benefit as it would create more maintenance work.
What is the best practice for n-tier application development using entity framework 4?
You should separate your entities and their persistence logic into separate projects. That way your Presentation layer will only need to reference the project containing the entities and be persistence ignorant.
I guess the projects breakdown as the following would be a nice approach (at least it has worked out well for me :))
Entities in one project
Persistence logic in another project (Repositories, Unit of Work
implementation)
WCF in one project
Presentation layer
Hope it helps.