MicrosoftNLayerApp Discussions Rss Feed

New Post: ¿Cómo compartir el mismo UnitOfWork por diferentes Repositorios?

allanob — Tue, 18 Jun 2013 17:53:11 GMT

Gracias Cesar!!!!

New Post: ¿Cómo compartir el mismo UnitOfWork por diferentes Repositorios?

cesardl — Sun, 16 Jun 2013 18:32:12 GMT

Que "Object Lifetime Mananger" de UNITY estas utilizando para la resolucion de tu UnitOfWork (EF DbContext)?
Si utilizas "PerResolveLifetimeManager" para la resolucion del UnitOfWork (EF DbContext), ese objeto sera compartido por todos los objetos del mismo grafo de resolucion de UNITY, lo que significa que sea compartido por los diferentes Repositories que estes utilizando dentro del mismo grafo de objetos resueltos en UNITY.

Sin embargo, al margen de que con ese lifetime manager lo puedes resolver..., cuestionate lo siguiente. Si tu problema de utilizar varios Repositories dentro del mismo Service no es por razones de consistencia de datos en consultas, sino porque quieres hacer una misma transaccion/actualizacion contra diferentes entidades, entonces, siguiendo los patrones de DDD, si tu transaccion engloba tres entidades diferentes (ej.: User, Membership y Profile), en ese Domain-Model contreto, probablemente esas tres entidades deberian formar parte de un mismo AGGREGATE: La forma de delimitar cuales son tus AGGREGATES debe de basarse precisamente en la consistencia requerida entre diferentes entidades y por ende, debes definir tus AGGREGATES basandote en las transacciones requeridas en cada domain-modelo concreto.
Por lo tanto, si tu AGGREGATE engloba esas tres entidades, y puesto que deberias tener un unico REPOSITORY por AGGREGATE (relacion 1:1 entre cada AGGREGATE-ROOT y REPOSITORY) que se preocupe por la consistencia de dichos objetos, entonces normalmente deberias de utilizar un unico Repository en cada transaccion, y ahi no tendrias ese problema tampoco de compartir un UnitOfWork (DbContext) entre varios Repositories. Puedes hacer excepciones, pero lo normal en DDD Domain-Models deberia ser eso.

No definas tus entidades y repositories up-front (directamente), piensa en las necesidades de cada domain-model concreto de cada BOUNDED-CONTEXT. Cada domain-Model de cada BC puede tener diferentes requerimientos de consistencia y por lo tanto, diferentes AGGREGATES y AGGREGATE-ROOTS.

New Post: ¿Cómo compartir el mismo UnitOfWork por diferentes Repositorios?

allanob — Sun, 16 Jun 2013 15:50:02 GMT

Hola Microsoft España,

Tengo un pequeño problema. Desde un servicio de la aplicación, que toma más de un IRepository, por ejemplo IUserRepository, IMembershipRepository, IprofileRepository etc. Despues crear un nuevo conjunto de datos, los tres repositorios deberían compartir el mismo UnitOfWork, para poder guardar los datos con un sólo UnitOfWork.Commit.

El constructor del servicio es el estándar para IoC y DI:

IUserRepository _userRepository;
IMembershipRepository _membershipRepository;
IProfileRepository _profileRepository;

AccountAppService(IUserRepository userRepository,
                                IMembershipRepository membershipRepository.
                                IProfileRepository _profileRepository)
{
    _userRepository = userRepository;
    _membershipRepository = membershipRepository;
    _profileRepository = profileRepository;
}

¿Cómo podemos establecer el mismo UnitOfWork para los tres repositorios?

Muchas Gracias,
Antonio

New Post: Generic Repository Inheritance

jlvaquero — Mon, 03 Jun 2013 07:21:42 GMT

Maybe it's not a good idea that specific repositories inherits from generic repository.

What if an aggregate root shouldn't be removed by domain rules? Specific repository must override Remove method and trhow NotAllowedException.

I don't like it. Specific repositories shouldn't expose unnecessary methods.

I think a best aproach is inject the generic repository in specific repository and use it internally.
Specific repository expose its own interface.

Example:

 public class BankAccountRepository: IBankAccountRepository
    {
       
        private IRepository<BankAccount> _genericRepository; 
        public BankAccountRepository(IRepository<BankAccount> genericRepository)
        {
            _genericRepository = genericRepoisitory;
        }

        public void Add( BankAccount item)
        {
             _genericRepository.Add(item);       
         }

         //Don't expose Remove method!!!
        //public void Remove(BankAccount item){}
            
    }

Generic repository and unit of work in generic repository can be injected by Unity using proper life cycle manager. Generic repository must expose unit of work to specific repository.

New Post: Load Child Collection & Unit Test & ObjectContext

descalada — Sun, 02 Jun 2013 07:11:05 GMT

Hello,

I have been using this architecture for some time and its great, but there is something I think I am missing. Let me explain in more detail.

What I want to accomplish is just to load a filtered related collection of an entity. If I do it as this post suggest http://msdn.microsoft.com/en-us/data/jj574232.aspx then my guess is like the number of queries could be even a performance issue.

The code in the repository will look like this

public IEnumerable<Trabajador> GetForEstimacionCoste(DateTime fecha)
        {
            var etts = UnitOfWork.CreateSet<TrabajadorETT>()
                .Include(t => t.Empresa.Tarifas)                
                .ToList();

            foreach (var item in etts)
            {
                ((DbContext)UnitOfWork)
                    .Entry(item).Collection(t => t.Contrataciones).Query()
                    .Where(c => c.FechaInicio.Month == fecha.Month)
                    .Load();
            }

            var company = UnitOfWork.CreateSet<TrabajadorEmpresa>()
                .Include(t => t.Convenio.PlusesActividad)                  
                .Include(t => t.CostesDivision)                
                .ToList();

            var all = etts.Union<Trabajador>(company).ToList();

            foreach (var item in all)
            {
                ((DbContext)UnitOfWork)
                    .Entry(item).Collection(t => t.Imputaciones).Query()
                    .Where(c => c.Fecha.Month == fecha.Month)
                    .Load();
            }

            return all;
        }

The code uses some Spanish words, sorry for that. And yes, that's a totally different discussion :)

So the test for the previous method in the repository will be something like...

[TestMethod]
        public void GetTrabajadoresForEstimacionCosteRepositoryTest()
        {
            var context = new WorkContext();
            var trabajadorRepository = new TrabajadorRepository(context);
            var fecha = new DateTime(2013, 06, 30);
            var resultado = trabajadorRepository.GetForEstimacionCoste(fecha);

            var etts = resultado.OfType<TrabajadorETT>();
            Assert.IsNotNull(etts.ElementAt(0).Contrataciones);
            Assert.AreEqual(1, etts.ElementAt(0).Contrataciones.Count);

            Assert.AreEqual(3, resultado.Count());

            Assert.AreEqual(3, resultado.SelectMany(t => t.Imputaciones).Count());
        }

And it is working. And it seems like fine, more or less. But as mentioned at the beginning I think there is a better way of doing it. Using the entity fixup of EF5. So that would mean loading all the related collections and then when querying the employees I will have the filtered collection just as I wanted to accomplish.

That would be something like...

public IEnumerable<Trabajador> GetForEstimacionCoste(DateTime fecha)
        {
            UnitOfWork.CreateSet<Contratacion>().Where(c => c.FechaInicio.Month == fecha.Month).Load();
            UnitOfWork.CreateSet<Imputacion>().Where(i => i.Fecha.Month == fecha.Month).Load();

            var etts = UnitOfWork.CreateSet<TrabajadorETT>()
                .Include(t => t.Empresa.Tarifas)                
                .AsEnumerable();

            var company = UnitOfWork.CreateSet<TrabajadorEmpresa>()
                .Include(t => t.Convenio.PlusesActividad)                  
                .Include(t => t.CostesDivision)                
                .AsEnumerable();

            return etts.Union<Trabajador>(company).ToList();
        }

Which works ok, but when trying to get the test passed I get an ObjectDisposedException: the ObjectContext instance has been disposed and can no longer...

I guess the issue here is the same one I tried to explain in http://stackoverflow.com/questions/16468252/count-method-in-repository-ef5 and my fear is the there is a concept I am missing.

I would like to have an explanation of why this is happening, why I can only reproduces with Unit Tests and which of the two options is the best approach for this kind of situations.

As the post is long enough I hide some details like the entities and so, whatever info you consider it relevant just let me know.

Thanks a lot in advance for your help.

Regards

New Post: Is it wise to abstract the entities?

JuanPabloRguez — Sun, 26 May 2013 12:05:24 GMT

Some key concepts that conform Dynamics CRM as an xRM, a valid solution from LA Council to a little retail shop, able to grow, scale and extend:

Metadata. That means that a "Contact" entity can be freely changed to whatever you want, for example, in one of my projects "Contact" (a person) was changed to "RFID Tag" (a vehicle) with very different properties. There's no "Contacts" table in database: there is a table "able to use" certain entities with some relationships, properties, forms, etc. Metadata shows you a "Contact" or a "RFID Tag" or any other concept, but the entity data stored in the database... is always the same. Metadata allows to adapt Dynamics CRM to any organitation, even if doesn't exist marketing or sales departament (Los Angeles Council). Anyway, Dynamics CRM database is transparent for developers and consultants. I never logged in the Dynamics CRM SQL Server database: this is the power of metadata-oriented database design.
DDD design. I don't know if all Dynamics CRM 2011 is a 100% DDD software, but for sure most part of Dynamics CRM follows this design patterns. For example, you can obtain all entities map from your Dynamics CRM implementation in Visual Studio and work with this "near to POCO clases" and CRM "DBContext", changing what you need. You can use Dynamics CRM elements like distributed software and independent layers and use WCF etc. For example, I've designed recently a complex BackOffice software that works with the Dynamics CRM entities etc separately, using Dynamics CRM almost "only" for UI and BI human interaction. Entity Framework Development Team uses the Dynamics Navision set of entities (similar to the CRM ones) for testing EF performance, isolated from the product. Scalability and extension capabilities of Dynamics CRM depends on this kind of design patterns.

What I'm trying to say is that Dynamics CRM is a xRM PLATFORM where developers can freely build a solid, flexible and scalable solutions. In complex situations Dynamics CRM becomes a "software development environment" while in most cases users can use "out-of-the-box" capabilities and build customizations themselves.

From a platform perspective, its difficult to talk about Dynamics CRM "funtionalities". The same happens if we talk about another platform: an aircraft carrier. Aircaft carriers can't fly. Dynamics CRM is ready to connect to or integrate enterprise software thanks to the metadata and DDD design patterns. This Enterprise software are the planes.

I think it's very difficult too - and expensive - to build a platform like Dynamics CRM even with a good design, even following the cesardl team patterns. Perhaps to follow this patterns building a solution over Dynamics CRM can be a better aproach. I think that today, custom applications development and platforms like Dynamics CRM or SharePoint are strongly connected worlds, even usually they seems isolated one to each other.

Por cierto César, vuestro trabajo es uno de mis libros de cabecera. Muchas gracias.

New Post: Development of Microsoft Spain

cesardl — Tue, 21 May 2013 23:50:06 GMT

Could be! J

Send me an email (to cesardl at microsoft.com) so we plan offline, ok?

There are quite a few things we could do..

Cheers,

Cesar.

New Post: Development of Microsoft Spain

brunobertechini — Tue, 21 May 2013 22:33:43 GMT

Cesar,

Would you like any help on getting this Project going forward? I really would like to help so submit patches or anything else I can do to keep this Project going...

Bruno

New Post: Is it wise to abstract the entities?

brunobertechini — Tue, 21 May 2013 21:08:19 GMT

Nice to hear that :)

Cesar, if you could have a look at these thread, I will appreciate:

Infrastructure.Logging - EventSource

WCF Error Handler

Regards

Bruno

New Post: WCF & Exception Handling Improvements for V2.0

brunobertechini — Tue, 21 May 2013 21:07:15 GMT

I figured out by myself:

I have changed the code from :

ApplicationErrorHandler.ProvideFault

//create service error
ApplicationServiceError defaultError = new ApplicationServiceError()
{
   ErrorMessage = Messages.message_DefaultErrorMessage,
};

To:

//create service error
ApplicationServiceError defaultError = new ApplicationServiceError()
{
   ErrorMessage = error.Message // Modified to include the exception raised
};

I have changed this so my custom exception type (DomainException) get forwarded to the client. (Of course I am forwarding only known exception - my custom type)

At the client:

try
{
     // Call proxy.Action
}
catch (FaultException<ServiceError> ex)
{
   properties.Status = SPEventReceiverStatus.CancelWithError;
   properties.ErrorMessage = ex.Detail.ErrorMessage;
}

Thank you very much!

Bruno

New Post: Is it wise to abstract the entities?

cesardl — Tue, 21 May 2013 19:42:16 GMT

Thanks a lot for the feedback Bruno! J

I agree with your comments, of course.

Cesar de la Torre.

Microsoft Corp

New Post: Buenas prácticas

brunobertechini — Tue, 21 May 2013 19:10:25 GMT

Well,

I have to tell you the "inconvenient" is a word that leads me to "maintenance problems in the feature" in your case.

I mean, every time you need something different on your View, you have to change your domain behavior. Is that correct?

Every time you need diferente business logic that may change properties of na existing entity, you would have to change every view that uses it.

Again: DTOs are not "for convenience" only. If you use them correctly and also create a Service Layer Approach you would benefit of separation of concerns.

I know its hard to build things "right". But thats the price to pay for a good system.

You can do it step-by-step. A very good approach is: REfactor your code as you have new features. Like: Every time you "touch" one class, refactor it to use DTOs. And when you realize, everything would be using it. So you can start phase 2 and create na intermediate layer like na AppService (from DDD).

I think you are not doing DDD right on App Layer. The App layer should be a mediation between Presentation (user) and the domain layer. You have the domain layer right on presentation.

If you want to have the benefits of DDD, my advice is to refactor your code slowly...but create a goal and work for it :)

Any help you need let me know

Bruno

New Post: Is it wise to abstract the entities?

brunobertechini — Tue, 21 May 2013 19:02:45 GMT

Hi Alex,

Sorry for the delay, but I am on a busy month (as Always) :)

My suggestion for you is: Embrace DDD and NLayerAppV2 as much as you can.
It will help you a lot if your system is intended to have a very long lifecycle and will stay there for a while.

I am working on a system I can call it medium/big and the advantages are so huge I cant think how I could work without these Technologies and approaches.

I am still on a learning courve, but I think I have solid practical implementations of NLayerAppv2-like Project by now. I am not using CQRS yet (still to come in next months). I am using Sharepoint 2013 to behave as my "Message Bus" and also for Presentation and sometimes App layer.

The thread you mentioned above was initiated by me a while ago. I was discussing with Cesar regarding basic methodology to get the hands on Bounded Contexts, Modules and others DDD terms in practical.

I will be very gratefull if I can help you guys in anything you need to design or code your app. I can do my best to provide you my suggestions and experiences :)

Again: I would definitely go for DDD and services-aware approach for a big solution as you are intended to build.
Regardless if current products do it or not. They may have tons of reasons to build the way they do: time, legacy versions, compatibility, lack of DDD maturity at the time of development, and many others.

So my final word is : Go for DDD, period. Talk to your business, define your entities/modules/bounded contexto and use NLayerAppV2 as a tech guide. Im sure you'll be happy in the future.

Regards

Bruno

P.S.: Feel free to share anything else or popup any other doubts/questions.

New Post: Infrastructure.Logging - Event Source

brunobertechini — Tue, 21 May 2013 18:50:23 GMT

Hi Cesar,

By now, I have almost 95% of my Project implemented according to NLayerAppV2.

Have to say: Its wonderfull. It really helps. Thanks a lot. And congratulations for the good work so far.

I have one question regarding ILogger:

Would you think its a good idea to create a method at ILogger interface to set the source string for a event log ? That would help a lot.

Like SetSource(string sourceName) so we can use it for eventlogs (Windows) , filenames (Text) and so on.

Would like to know your thoughts about it.

Regards

Bruno

New Post: Is it wise to abstract the entities?

Cyberdude3 — Fri, 17 May 2013 09:14:38 GMT

Hi Bruno,

No. We are not going to build on top of any CRM. I wanted to give an example to clarify the type of our application. So, it would be a completely separated application with almost the same functionalities as most CRM applications.

Alex

New Post: Is it wise to abstract the entities?

brunobertechini — Fri, 17 May 2013 00:59:46 GMT

Hi Alex,

Are you going to build your App on top of Microsoft CRM or would it be a completely separated app?

Bruno

New Post: Is it wise to abstract the entities?

Cyberdude3 — Thu, 16 May 2013 19:08:25 GMT

Hi,
We want to build an enterprise application which does have many CRM functionalities. And we are stuck with a very important architectural decision. When we look at Microsoft CRM 2011 we see that all entities are in the database. It looks like that there is a huge abstraction layer similar to CMS has been build and used to build the application. As the result without using SDK, a programmer should write code like dynamic["Account"] to get the customer instead of just write Account acc = new Account().
Well, we don't want to rebuild the MS CRM, we just want to know is it wise to build an application which
1- has multiple different UI and services (mobile app, windows service, asp.net mvc web)
2- has accounts, products, orders, bills, discount and that kind of entities
3- and the products has many different attributes and dependencies on each other

with an CMS?
Because to me, a CMS makes entities abstract by defining each as a as content. So you could see all entities in the some database table of the CMS. Just like most CRM's have.

Or we could use an architecture like this great example of Domain Oriented N-Layered sample application. When we do that, we will use entlib 6.0 and Unity 3.0 as well and build WebApi's for all type of client app's.

I know that without the knowlegde over the domain nobody can make such decision or advice. But see it as a CRM application.
By the way this post https://microsoftnlayerapp.codeplex.com/discussions/431320 was also help for us. But didn't make the decision any easier :-)

Any help would be greatly appreciated.

Regards,
Alex

New Post: Buenas prácticas

fjaumot — Thu, 16 May 2013 18:41:41 GMT

Hello!
I understand you now! :)
Yes, this is a inconvenient but this is not compensable work involved in creating DTO project where there are many entities (97 in this and 192 on the other we have with DDD). Is there any way of linking OFF, automatically create them, etc. ..?

Thanks for all!! :) it's a great conversation with u :)

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 17:01:29 GMT

fjaumot wrote:

Hello Bruno, !
Beacuse I need the DTO? I dosen't understand this.
I have,

UX (mvc)
Project.BackOffice (ViewModel, Controller, Js, View...)

Application
Project.Application (use repositories and entities)

Domain
Project.Domani.Entities (Created by t4 and used in Application and UX)

Data
Project.Data (EDMX, Context (t4) with UnitOfWork and Repositories)

I dosen't understand because I need to use DTO... Because I dosen't use POCO Entities??

Thank you!!

Because, in my opinion, you should never use Domain Entities outside the domain and Application Layers.

Simple example: If you have "full rich entities" right at the controller, why do you have Application layer?

For example, lets say the Invoice entity has a "Process" method. And youre suppose to handle it using na AppService right? like you did InvoiceManagementService.

Regardless the existence of this InvoiceManagementService, right on controller you can do something like:

invoice.Process() --> And this would break something in your domain since youre not using your Application logic from InvoiceManagementService.

Business logic should never leave domain boundaries.

I try to use a mix of DDD and Union Architecture for better maintenance:
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Bruno

New Post: Buenas prácticas

fjaumot — Thu, 16 May 2013 16:47:53 GMT

Hello Bruno, !
Beacuse I need the DTO? I dosen't understand this.
I have,

UX (mvc)
Project.BackOffice (ViewModel, Controller, Js, View...)
Application
Project.Application (use repositories and entities)
Domain
Project.Domani.Entities (Created by t4 and used in Application and UX)
Data
Project.Data (EDMX, Context (t4) with UnitOfWork and Repositories)

I dosen't understand because I need to use DTO... Because I dosen't use POCO Entities??

Thank you!!