I am learning the Domain Driven Design and I saw some concepts the following Aggregate, UnitOfWork,... I am reading the books that including java based applications. But Entity Framework is growing up in .Net framework. Entity Framework is including DbContext, IDbSet,...
Is there a nice sample that applied domain driven design in .Net
Matching the concepts
I personally think that Microsoft Spain has done a great job in providing a learning example. It's not for the "faint-hearted", and it's not the "only way to do it", but you may find it interesting. Have a look at https://microsoftnlayerapp.codeplex.com/ ?
Related
I am new to Entity Framework. The concept of a Bounded Context would work perfectly in a project I'm on, but I don't know how to implement the design.
This article by Julie Lerman, Data Points - Shrink EF Models with DDD Bounded Contexts explains the concept nicely but doesn't show exactly how to achieve the result.
In the article she says she uses Entity Framework 6 Power Tools. Is this the same as the NuGet Package "EntityFramework.ToolKit?
Are there any useful examples out there?
I've read some articles (Stackoverflow, Wikipedia, Simone Busoli, etc.) about Inversion of Control (IoC) and am starting to get my head around the concept. I've also been studying the Entity Framework (EF) and am wondering where specifically IoC is present within the EF? Here's a simple EF example I've been looking at: (EF Code First: new DB)
Inversion of Control is a pattern that aims at loosely coupling an application. It puts the application in charge of all of its dependencies (whether or not they are in libraries or frameworks).
EF is not an application, it is a library. You can wire it up with IoC, but since it is not an application, it contains no IoC.
That said, it is possible to develop frameworks and libraries to be IoC or DI (dependency injection) friendly. There are a couple of great articles on that topic:
http://blog.ploeh.dk/2014/05/19/di-friendly-library/
http://blog.ploeh.dk/2014/05/19/di-friendly-framework/
Mark Seemann (the author of that blog) has written a great book on the subject of DI in .NET, which I highly recommend because there is a lot of misinformation and outdated information on the web about IoC and DI. I am confident once you read the book you will understand how to use IoC with EF, but it is not something that can be answered in a paragraph or two.
I couldn't found a clear answer on that:
Is the ADO.NET Entity Framework a full featured persistence framework like Hibernate for Java?
Is there a any (other) persistence framework in .net? I only found open source frameworks like nHibernate but no clear answer if there is something build-in in .net. What's the best practice to get persistence in .net?
when you talk about persistence layer, usually that is databases or file systems, when you talk about Entity Framework it is called ORMs, and yes, I think in the .Net environment NHibernate and Entity Framework should be two of the most popular ORMs.
ORMs help you to think about your data as objects in your domain, instead of thinking about tables and fields and rows, so it abstracts the technical aspect of persistence and gives you a more model-driven approach while you are writting software.
I use to read a lot about domain-driven design as an architectural guide, but now here in stack overflow I've received many suggestions on using hexagonal architecture, all these patterns and practices help you to buidl better software, and I guess we will never stop learning. So yep, think about ORMs like artifacts to help you focus on more important aspects of your code rather than just making tables and querys. Hope it helps,
I'm having a look at Entity Framework and everything I'm reading takes a data centric approach to explaining EF. By that I mean that the fundamental relationships of the system are first defined in the database and objects are generated that reflect those relationships.
Examples
Quickstart (Entity Framework)
Using Entity Framework entities as business objects?
The EF documentation implies that it's not necessary to start from the database layer, e.g.
Developers can work with a consistent
application object model that can be
mapped to various storage schemas
When designing a new system (simplified version), I tend to first create a class model, then generate business objects from the model, code business layer stuff that can't be generated, and then worry about persistence (or rather work with a DBA and let him worry about the most efficient persistence strategy). That object centric approach is well supported by ORM technologies such as (n)Hibernate.
Is there a reasonable path to an object centric approach with EF? Will I be swimming upstream going that route? Any good starting points?
Model First approach seems to be what you need.
We suggest to take a look at the ADO.NET Team Blog article also.
A while after asking this, I discovered that EF 4 supports POCO (Plain Old CLR Objects), allowing an object-centric design with (relative) ignorance of persistence.
This article was the best one I came across discussing that approach, while this article explains how to use code generation templates to ease the work.
I’m working on a high volume transactional enterprise application(asp.net, windows app, oracle app as client) which has been designed using n-tire application and SOA architecture .The application was developed in the .NET platform utilizing C#,VB.NET, Framework 3.5 (I’m planning to upgrade to the , Framework 4.0), EF( EF in the data layer level) and WCF(WCF services in the service layer level)
Since this is the first project using EF, and having read about using EF in n-tier and SOA applications, and the features available in the EF Feature, I have the following points:
Which design pattern should I use in EF( Simple Entities, Change Set, Self-Tracking Entities and DTOs) in the data layer level
In addition Which design pattern should I use in the other tier and layer to get the best practices of EF
Thanks
"In addition Which design pattern should I use in the other tier and layer to get the best practices of EF "
I would use the saperation of concerns using IoC at the root of my design patterns. for Data Layer Abstraction purpose I would definately go for Repository patterns. There are some interesting work which you see on the web for e.g. UnitOfWork for transactions etc.
Not sure about your knowledge in Repository pattern but here's a good start.
There is also a good project on the CodePlex called Project Silk which can give you a good heads up for both the above topics among others.
All the best