-
-
Notifications
You must be signed in to change notification settings - Fork 92
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 requiredTimeEntryActivity
for theActivity
property. 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 theNameValueCollection
parameter. 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
ISerializer
interface 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.Issue
instead 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