danludwig / tripod Goto Github PK

I am not currently using your command-structure of querying or writing the database, as my project is not that large.

Instead I am using services, which I call from my controllers to move my business logic away from my UI layer. This service has a dependency on IReadEntities or IWriteEntities. Now my question is, when my controller is dependent on this service, what is the best way of calling .SaveChanges()?

At the moment the .SaveChanges(); is on IWriteEntities (IUnitOfWork), so from my service class I call _entities.SaveChanges(); in my Create/Update IService implementation after _entities.Create(entity);

My concern is that if I update multiple entities I am calling .SaveChanges(); multiple times (from the services) instead of just once from my controller?

Next question is, if my service does both read and write actions, I would only use IWriteEntities? As IReadEntities deattach the entity from the change tracker of EF?

Thanks Dan! ;-)

Jan

Hi,

Nice project! I came here from this SO post: http://stackoverflow.com/questions/21349950/entity-framework-6-code-first-is-repository-implementation-a-good-one

I'm trying to implement those IUnitOfWork, IReadEntities etc. But how do I use them in a controller? The way you wrote the code is too advanced for me to understand it.

If you could clarify it a bit, I'd really appreciate it!

One more thing, how do I set up my database to work with it? I'm using Code First.

Hi,
I'm choosing the architecture for an EF/Web.API web application I'm working on. I'm evaluating several alternatives and I really like your Tripod approach.
I'm trying to test this solution in visual studio 2015, but I'm having some build-time errors in some .ts files (all errors are in the Tripod.Web project, built with the "Debug" configuration):

• Error 1: Build: Argument of type 'JQuery | string' is not assignable to parameter of type 'string'.
  File: --SolutionDir--\Tripod.Web\app_common\unobtrusive\bootbox-confirm.ts Line: 8
• Error 2: Build: Type '{ preprocess: (value: string) => string; update: (element: Element, valueAccessor: () => any, all...' is not assignable to type 'KnockoutBindingHandler'.
  File: --SolutionDir--\Tripod.Web\app_common\widgets\BindingHandlers.ts Line: 6
• Error 3: Build: An index expression argument must be of type 'string', 'number', 'symbol, or 'any'.
  File: --SolutionDir--\Tripod.Web\app_common\widgets\BindingHandlers.ts Line:12
• Error 4: Build: Type '{ value: (other: any) => any; validator: (val: any, otherField: any) => boolean; message: string; }' is not assignable to type 'KnockoutValidationRuleDefinition'.
  File: --SolutionDir--\Tripod.Web\app_common\widgets\ValidationRules.ts Line: 47

Please, as I'm a bit new on the .ts world, could you help me figure out how to solve these errors?
Thank you so much.
Matteo

First I would like to say thanks for making this excellent pattern publicly available.

I am in the process of refactoring my C# Web app to mimic your tripod pattern, and I am a getting a little hung up on where I would initialize the connection to the SQL database and store the context as well where I would store the EF 6 auto generated models for the SQL database. All while remaining in accordance with your pattern.

I see that you have your Model Entities in Tripod.Domain, but the Entity Framework model builder and the related app.config is in Tripod.Services. I assume this is because the code first db generation is considered as a service?

If I were to stick with my current EF database first design, should I also put my Model Entities in Tripod.Domain or should it remain with its root .edmx file in Triforce.Services? And then would I initialize my main DB entities in something similar to BrownfieldDbInitializer?

Sorry if these questions are a bit naive, I am still in the process of wrapping my head around the tripod pattern.

Hi Dan
I am really impressed by your work. You have certainly read lots about program design and this skeleton has some superb patterns. I came across it by trying to avoid writing/maintaining lots of identical repositories (which the DDD pattern seems to impose on us).
It seems like you have worked around most of the MANY pitfalls of ASP.NET Identity 1.0 also (like email-confirmations, remote memberships, etc.). However, many of these have been addressed in Identity 2.0 making lots of the code in this project obsolete (in my superficial view, that is).
Do you have any plans on adapting this project to Identity 2.0?
Best regards, and thank you for sharing your experience with the community.
Lukas

I admire the architectural design in this project, it helped me to understand the design patterns and how efficiently they can be used in a real world application. By the latest SimpleInjector, there are things got obsolete, and there are things that are in use not being recommended by them. I am eager to see what type of replacements you would use with the latest SimpleInjector update.

Thanks in advance

I got a good understanding of CQRS pattern looking at your code. I've got couple of
questions.

• I see that to implement CQRS, it requires lot of classes to implement. For
  example, to get the HashedPassword, there is a class to return a string. The
  same code would have been fit in a function when repository pattern is used.
  Imagine there is a large database with many tables and columns. There would
  be so many classes and so much code to write to do simple queries. Even
  though code is easy to read in CQRS, more code means more maintenance. What
  are your thoughts on this?
• You have IUnitOfWork declared but not used anywhere. Do you intend to use
  it in future?

By the way, I really really liked the IWriteEntities and IReadEntities
interfaces on DBContext in place of generic repositories. I would want to
use it in one of my projects and see how it goes.

Thanks so much for your input.