is there any code or docs about implement asp identity in clean architecture and how to apply CRUD operation in Application Layer with User Entity that inherit from IdentityUser in Domain Layer
I implement Asp identity in Domain Layer any ideas ??
I forget to mention that I use CQRS in Application layer
Here is a nice article provinding a lot of information on how to implement a clean architecture using DDD TDD and Identity.
Hope it covers your needs.
Related
hi i need to know if is possible develop a webApp following Action Domain Responder architecture with fat-free framemwork.
i have used it to do MCV webAPP but i don't sure is the framwork framework to do and APP with Action Domain Responder architecture.
Thanks.
Sure you can build pretty much every architecture you want with fat-free, since it only is a microframework at its core, but YOU have to build it by yourself as fat-free is not dictating any structure. I've once build a RMR like architecture for fun with it, so yes you can if you know how to. ADR seems to me like another term for Domain-Driven-Design, which is a good choice. Good luck ;)
I want create a demo of an integration of ESB with the Adobe AEM. Even a very basic one will suffice. I need to understand if :
1. Is this is Possible/feasible?
2. How can one achieve this?
Please let me now if you have any questions.
Your question is a little broad.
What does "integration" mean in your context?
AEM ist built on Java Technology.
If your ESB provides a REST interface (or SOAP or RMI or JNI etc) you could access it in a component or a servlet etc.
You may want to look at this to get a clearer picture:
http://www.cognifide.com/blogs/cq/four-approaches-to-integrating-aem-with-external-systems/
We have an application that is heavily used. In this application we have business logic in our viewmodels and in the service layer
Now we need to migrate the app to html because of performance issues, plus considering that Microsoft throw out the support for this technology.
We can't just stop the application for several months to finish it's migration. Our clients needs to use it. My first approach will be to migrate all the business logic to the services, making the app a thin client, so we can later use the services for ayax calls in a new ui, made with html
Do you have any experience with this migrations? What are the pros and cons?
We are currently doing one of these projects
what I would recommend is following
Have all business logic that aren't UI specific or silverlight specific in its own Business Libraries.
Put a service layer WCF or WebAPI (REST) on top of the Business logic so all the business logic can be accessed via different technologies
Use AngularJS or ASP.NET MVC + AngularJS combination so you can keep MV* pattern going and most probably use most of your ViewModel logic with bit change while giving some what similar experience to customers that are used to silverlight UI
1 and 2 was very important in our project because it gave that clean separation and flexibility to expand to any client machine without changing minimum code. Ex: later if we decided to make an Android app you just have to transfer only viewmodel logic without touching your business logic or services.
Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.
It's confusing to categorize something into a model, and others into services. Is their any good thumb rule, help of which i may distinguish between a service and a model. I tried to look into various mvc docs, but almost all of them talk about model-view-and controller. Nothing about services.
Thanks
I would advise you to take a look at Robotlegs.
It is an ActionScript MVC(S) framework that promotes looser coupling between components, and has hooks to handle models and services accordingly.
Rules of thumb to distinguish whether to use a Service or a Model are described thoroughly in the documentation.
In short, a Service would be used to connect your application to the outside world, thus bringing external state into your application.
Whereas a Model would be used to store internal application state.
Robotlegs also features a handy IOC container.
You will be able to either implement your application with this framework or you could get a lot of ideas from looking at the framework code.
Check these out:
http://www.robotlegs.org/
http://www.robotlegs.org/diagram/