Web UI - Models/ViewModels for Request and Response.
BLL - DTO
Data Accesss - Entity Design.
I am mapping Model to DTO in Web UI Layer and mapping DTO to Entity Design in BLL layer.
I have added below line in ConfigureServices method of Startup class.
services.AddAutoMapper(Assembly.GetExecutingAssembly());
I am able to map in Web UI layer but while calling service layer it throw below Error:
System.MissingMethodException: Method not found: '!!0 AutoMapper.IMapper.Map(System.Object)'.
Can anyone suggest me the better way to keep separate BLL mapping profile and Web mapping profiles ?
I found a great article
https://www.abhith.net/blog/using-automapper-in-a-net-core-class-library/
I resolve this by implementing ObjectMapper in BLL.
Related
I want to build a viewModel for entire the application to send and receive data between multiple fragments and activities. so, how can I do that
Do not implement ViewModel scoped to the application
From Wikipedia article:
The viewmodel of MVVM is a value converter, meaning the viewmodel is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the viewmodel is more model than view, and handles most if not all of the view's display logic. The viewmodel may implement a mediator pattern, organizing access to the back-end logic around the set of use cases supported by the view.
From ViewModel class documentation:
ViewModel is a class that is responsible for preparing and managing the data for an Activity or a Fragment. It also handles the communication of the Activity / Fragment with the rest of the application (e.g. calling the business logic classes).
A ViewModel is always created in association with a scope (a fragment or an activity) and will be retained as long as the scope is alive.
ViewModel's only responsibility is to manage the data for the UI.
It's clearly defined that ViewModel is a binder between View and Model and nothing more. Currently only Activity, Fragment and their subclasses implement ViewModelStoreOwner interface allowing ViewModel be scoped to them.
Also Application scoped ViewModel violate the important SOLID principle - Interface segregation (ISP). It states following:
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
How to send and receive data between activities and fragments?
Some ways to communicate easier than application ViewModel:
Between activities via Intents
Between fragments via Bundle, via Navigation Component with Safe Args and via ViewModel
Between activity and fragment via Fragment.setArguments()
I need to add custom attribute to all spring integration component for example - need to add 'description' attribute to all inbound and outbound gateway.
Once we are able to add the custom attribute, I need to log the newly added attribute - 'description'.
Can you please suggest the approach for this.
Thanks
I've explained you how it isn't going to be possible because if Java nature. Now let's try to imagine what we could do on the matter. You can register some additional support beans in the application context and have their relationship to the integration components. For example through some id pattern or key-value store like simple HashMap. So, this way you always will be able to extract that additional information whenever you get access to the original component: or rely on its id or call the map registry.
I have a set of Services that I want to use in various ServiceStack projects (okay, two) so I have created a ServiceStack Plugin that registers them.
However I want to allow users to determine their own method of securing access to these services.
Currently I have an IHasRequestFilter in one my projects that can determine which services a user should be able to access. I do not want a reference to this in the Plugin project, so I want to add this dynamically after the fact.
I want to somehow get a reference to the Service Definition in AppHost to add this IHasRequestFilter to the pipeline for a specific set of services.
Ideally I should be able to do something like this:
new CustomPlugin(new CustomPluginParams {
RestrictTo = CustomRestrictions,
RequestFilters = [],
ResponseFilters = []
});
This should use those properties to configure their services without having a previous typed reference.
Edit:
Investigating further it appears that the IHasRequestFilter and IHasResponseFilters are only parsed once, in the ServiceExec<TService> class. I could get round this by creating my Services with a Proxy which adds the attribute I require to the MemberInfo of the operations, however I don't regard that as a clean approach.
Does anyone have recommendation?
In ServiceStack all configuration should happen within AppHost's Configure() method and remain immutable thereafter.
Lifecycle Events
To help with LifeCycle events there are IPreInitPlugin and IPostInitPlugin Plugin Interfaces which your Plugins can implement so they will get called back before and after all plugins are registered.
There's also an IAppHost.AfterInitCallbacks plugins can use to get called back after the entire AppHost has finished initialiazing.
Typed Request/Response Filters
Attributes are typically statically defined on Services, to dynamically add logic that apply to specific Request/Responses you can use a typed Request/Response filter.
The nice thing about ServiceStack Filters is that they share the same API (IRequest, IResponse, object) which makes them easily composable, e.g:
RegisterTypedRequestFilter<CustomRequest>(new RequestAttributeFilter().Execute);
Dynamically adding Attribute filters
As all ServiceStack libraries use ServiceStack.Text's Reflection API's you're able to extend ServiceStack's attribute-based code-first API dynamically by adding attributes to types or properties at runtime, e.g:
typeof(CustomRequest)
.AddAttributes(new RuntimeAttributeRequestFilter());
This can be done for most of ServiceStack's code-first API's inc. Request/Response Filters.
Route attributes and Action Filters
There is sometimes an issue for Services Route attributes and Action filters that already pre-configured and autowired before the AppHost's Configure() is called.
One solution is to add them in the AppHost constructor (or by overriding AppHost.OnBeforeInit) so they're added before the Services are configured. Otherwise you can reset the action filter caches by calling the AppHost's ServiceController.ResetServiceExecCachesIfNeeded().
I am writing an Class Library as DataModel. DataModel capable of handling all the Database related task. I am using NHibernate and Fluent NHibernate for the same.
Now the question arises are as follows :
Should we expose the Entity (POCO Class).
Is it good to have a Entity with internal protected property and property exposed as a interface.
Entity created for mapping can be a Model for WPF MVVM.
Or should we directly bind entity ?.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Is it right to throw Exception occurring in an API or should I return null?.
Is it good keep logging in the Library ?.
Should we expose the Entity (POCO Class).
Yes, Creating wrapper class makes more effort.
Is it good to have a Entity with internal protected property and property exposed as a interface.
Yes, Setter and non-exposed properties are control.
Entity created for mapping can be a Model for WPF MVVM.
For primitive type can be, but reference can be exposed by interface.
Or should we directly bind entity ?.
If Model is created rather directly use of POCO object. It is much more flexible for refresh cases. User can not change property of POCO object if cancel operation is there.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
IEnumerable is used to exposed collection by interface.
Is it right to throw Exception occurring in an API or should I return null?.
Exception is much more better to make know to user about error. but wrap the exception in user readable rather returning NHibernate exception.
Is it good keep logging in the Library
Logging is very good feature to know about issue.
Should we expose the Entity (POCO Class).
yes, otherwise whats the use of the entities when nobody uses
Is it good to have a Entity with internal protected property and property exposed as a interface.
It depends! internal protected properties are no problem when using an ORM but i prefere to reduce internal stuff to a minimum because i like objects maintaining their own state. interfaces are fine
Entity created for mapping can be a Model for WPF MVVM.
of course. No need to duplicate them another time. That's what persistence ignorance is for
Or should we directly bind entity ?
More ofthen than not, the UI requirements are very different than persistence/businessrules so there will be specialised ViewModels for UseCases/Views. However simple Dataholders like Order class thrown into Lists can be bound directly (e.g. using a DatabindingFactory to make them implement INPC)
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Lists are just in memory container. The user still has to go through the API to Save/Update state.
Is it right to throw Exception occurring in an API or should I return null
if collections are returned then empty collections are far better than null.
Exceptions however should bubble up preferably wrapped in own handable Exceptions. Implement NHibernate.Exceptions.ISQLExceptionConverter (e.g. like NHibernate.Test.ExceptionsTest.MSSQLExceptionConverterExample) and configure it with e.g.
config.DataBaseIntegration(db => db.ExceptionConverter<MyExceptionConverter>())
Is it good keep logging in the Library
absolutly. Logging enables debugging deployed applications. (Fluent)NHibernate already has lot's of logging built in use it if possible.
I am new to DDD but I am trying to implement it in my Project - I have a service which is setup following the DDD principles - Application / Model / Repository - The Clients of the Service want to get back a DTO class (which also contains a Error Collection as one of its members) . Questions is how do I populate the Error Collection of the result DTO. Can the Error DTO be passed from the Application/Service Layer to Model/Service layer and populated there – Can someone point me to some example of these kinds of scenarios Currently I am bubbling up all the errors that I am getting back to the Application Service and populating it there like I said I am struggling.
As a general rule try not to copy code (classes, methods, interfaces). If you really have to use DTOs create them as late as possible in the process so that if you remove them you should still be able to use the system in another way.
I would have something like this:
Model
Domain classes
Error class
Model/Service (has reference to Model)
Application/Service (has reference to Model and Model/Service)
Domain DTOs
Error DTO
Also a question do you really need two Service Layers? Avoid Anemic Domain Model