-
-
Notifications
You must be signed in to change notification settings - Fork 93
Open
Description
Hi,
thanks for maintaining this project.
I'm using your project in a small bridge project between different systems.
Maybe you want to improve the usability of the library, so here's my feedback after working with it for two days:
- The first thing I noticed are some inconsistencies. For example, I want to create a
TimeEntry, so I'm loading the requiredTimeEntryActivityfor theActivityproperty. But wait, I can`t assign my retreived activity since there are some type shenanigans going on. Related to Version 3.0.6.1 makes IssueCustomField.Info readonly breaking existing usage #253 - Not all redmine APIs support filtering, so there should be a built-in
GetObjects<T>()-method (without theNameValueCollectionparameter. Or even better, create individual services per type, to support individual queries (GetProjectsByIdOrIdentifierAsync(string id)for example). - You should get rid of controlling the serialization and deserialization of models inside the models. Why don't you just create a
ISerializerinterface and implement it per XML and JSON? Because of the limited object (de)serialization capabilities, I cannot serialize the object by myself to cache them. For now, I sticked with custom dtos to make them cacheable properly. - Consider separating your classes by areas and not by types. imho the API feels more organized if I access a service or model by it's area:
Redmine.Net.Issues.Issueinstead ofRedmine.Net.Types.Issue(i'm thinking about something likeRedmine.Net.Issues.IRedmineIssueClient, so you have all related models in the same namespace. - User impersonation should provide a limited scope. Maybe something like:
using(var apiAsUser = redmineManager.ImpersonateUser("loginname"))
{
// do something
}- The project itself feels a little bit "sluggigh" or instable.
Metadata
Metadata
Assignees
Labels
No labels