Quote from Jes Kirkup on February 8, 2018, 11:15 am

Just my personal observation here ... 🙂

Do we really need the additional complexity of the IUnitOfWork and IRepository pattern interfaces here?

https://cpratt.co/repository-and-unit-of-work-patterns-with-entity-framework/

"Some of the other methods are slightly more complex, but still amount to merely proxying a call from the repository to a nearly identical call in Entity Framework. Why is that the case? Well, because ORMs like Entity Framework already implement the Unit of Work and Repository patterns. Specifically with Entity Framework, the DbContext is the Unit of Work and each DbSet is a respository. People tend to follow patterns without thinking about the reason for those patterns. A pattern, in general, is merely a codified way of solving a problem. It's therefore only useful if you need to solve the same problem its meant to solve. "

Quote from Jonathon Wyza on February 9, 2018, 2:12 am

Yeah, even MS seems to agree now: https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/advanced#repository-and-unit-of-work-patterns

Quote from Eben Monney on February 10, 2018, 1:28 am

Quote from Jonathon Wyza on February 5, 2018, 5:59 pm

I noticed that in the sample, you create an IUnitOfWork to access the DLA for everything other than the AccountManager.  Is there a reason for this?  Is there a way to simply tie a inherited IRepository directly into DI?    IE:

public interface IWidget : IRepository {}

then

public MyController(IWidget widget) { _widget = widget; }

 

PS: Since this is a forum designed for developers, I'd suggest seeing if you can update your WYSIWYG editor to include code blocks with syntax highlighting.  I don't seem to see a quick way to do that (or if there is one, it's "hidden")

Accessing your Repositories through a UnitOfWork is a recommended practice. It provides a clean way of grouping data entities that are related to (or have been affected by) a specific operation and an isolated way of saving them to the underlying data store or discarding. As the name implies a "Unit of Work".

This can be all the modifications you've made in relation to a specific operation such as a customer purchase. In such operations a series of entities are affected/modified and a UnitOfWork isolates all those changes specific to that single operation.

PS: For the syntax highlighting that's available, just not in the forum. There's a security concerns that will be addressed before that can be enabled. In the meantime copying preformatted code (e.g. from VS) transfers the syntax highlighting

Quote from Eben Monney on February 10, 2018, 1:38 am

Quote from Jes Kirkup on February 8, 2018, 11:15 am

Just my personal observation here ...

Do we really need the additional complexity of the IUnitOfWork and IRepository pattern interfaces here?

MOST DEFINITELY YES.

The Repository and Unit of work patterns isn't a Microsoft thing. It’s a pattern that applies equally to other technologies/vendors. There is sure a debate on the degree of abstraction that's necessary for any particular project, but there's a general consensus on the benefits of this pattern and it is recommended for medium to large scale projects.

Microsoft tries to have a generalized implementation of it in its Entityframework so developers can reap the benefits out of the box. But this introduces an inherent problem. i.e. tight coupling of your code to the framework.

By having an implementation of the Repository pattern, you decouple your application from entityframework (or any other ORM). This enables you to swap entityframework for other orms (such as nHibernate) with minimal effort.

Persistent frameworks in general change every few years (e.g. ado, Linq to SQL/Entityframework 1 to 6 and now core) and building applications to be tightly coupled with one specific framework just ties you down.

The implementation of the pattern in QuickApp is standard and not over engineered. It provides a good skeleton for you to flesh out. But by no means are you forced to use it (as you can see with the implementation of AccountManager).

Once the general structure has been setup as with QuickApp, it is not difficult to follow this pattern in your project and it serves as a good guide. It is up to the developer to decide the degree of decoupling needed for their project (as is the case with Jonathan's comment above), but I'll recommend a pattern of this sort to prevent tying your code to 3rd party libraries whilst increasing reusability.

Quote from Jes Kirkup on February 10, 2018, 10:46 am

Fair enough Eben I appreciate your response and I understand your reasoning 🙂

However in my case I have no intention ever of swapping out EF for anything else (just because you can doesn't necessarily always mean you should or would).

Also, I don't think I agree entirely with your comments regarding the percieved volatility of ORM.  I have myself used my own XSLT template based boilerplate DAL code generator that I can apply any pattern I choose and no external ORM dependency whatsoever. There is a lot to be said for avoiding black boxes and dealing directly with SQL where complex queries may be desired.  My templates are based on ADO.NET and works with any version of .NET ever produced.

I'm using EF code generation too but it would be trival for me to switch to back to using my own or another templates.  The Web API itself already is an abstraction and decoupling from the client perspective.

I'm not arguing that is no merit in the pattern or that it wouldn't be straightforward to implement this pattern, its just honestly I'm struggly to see what actual "real world" benefit I would gain from doing so in my particular situation. Swapping out ORM's hasn't been a practical issue for me in my 20+ years of coding database apps.

By the way may I say that I am massively impressed with the work that you have put into this template.  I'm using it as the basis for my current project.  The built in localization is really nice to have their OOB.  I'm new to Angular so it is a great help for me.

All the best

 

Jes

Quote from Eben Monney on February 10, 2018, 12:43 pm

Agreed.

Design patterns are merely a well known guide to prevent common pitfalls that may later crop up in implementations.

Which design strategies to adopt to prevent these pitfalls is up to the developer.

Thanks for the discussion and I'm always keen to learn the user's point of view.

Glad to hear this template was of help.

 

Cheers,

Eben Monney

Quote from keith on April 10, 2018, 10:03 pm

Great discussion here. Eben did you use a generator to generate the Customers / Orders  / Products DAL? Did you use Code First or Database First? Please post any in information on your specific process. I have not done much of this before. I have an existing project I am refactoring using QuickApp Pro to develop on and would like to have these layers generated from my existing database if possible. Thanks!