i though that a vocabulary was a special type of directory or that at list a directory could provide a source for a vocabulary. It seems notData List and directories. What i want to acheive is to plug my taxonomy server into nuxeo. In other words, i would like nuxeo to use taxonomies that are defined externally. Isn't the directory abstraction meant for it ? The taxonomy server provide some rest service for external access.
Yes the directory abstraction is designed to abstract lists like yours. You need to implement a new Nuxeo component and implement a org.nuxeo.ecm.directory.DirectoryFactory and a org.nuxeo.ecm.directory.Directory as well as a org.nuxeo.ecm.directory.Session. It's not as easy as it should and involves a few classes, but it's quite feasible.
You can take as an example the SQL implementation in nuxeo-platform-directory-sql to get an idea if what's needed.
Related
We're refactoring our solution to a Domain Driven Design structure. Our consultants which implement the software, should be able to customize some behavior of the application (for specific customers needs). For example they want to add custom defined properties to the presentation (user input forms) and save the custom data together with the entities defined in our DDD projects.
However, the domain objects should preferably not contain a customData property. I don't want to mix those and let the domain object know that there's something like custom data. I'm saving en fetching the entities by Repositories.
How do I make this scenario possible? One possible solution would be:
Query the entity by using his Repository
And query separately the CustomPropertiesRepository by entity ID.
Combine the two queries objects.
When saving the forms. It will be splitted again using two repositories
The disadvantage of this, is that I have to query twice though it should be one document.
Any advice on this problem?
in general dynamic properties are better suited for data-centric design and in my opinion this practice is not suitable for DDD.
in DDD the code must reflect the knowledge of the domain, it must be simple and explicit.
before thinking of the best way to persist a dynamic property, you must solve the problem at the design level:
1-There are three possible artifacts for a property: aggregate root, entity or object value.
2-usually a dynamic property brings with it a functional need (calculation, validation ... etc), where you will implement this functionality? whether in the aggregate root or in a domain service you will be compelled to compile your code and here the dynamic propriety loses its meaning, unless you think use a Business rules engine, and there you introduce another new paradigm with its whole complication, and some of your business logic would be outside aggregates and domain services.
I want to define some constraints for my profile. For example I need a constraint for a stereotype of the metaclass "connector". I want to define that these element must have one source like the oclkindof(source) and one target like the oclkindof(target). I found some texts by using the Google search engine like http://modeling-languages.com/wp-content/uploads/2012/03/OCLChapter.pdf or http://www.omg.org/spec/OCL/2.0/ and other slides and papers but not the right description of OCL for me.
Best regards
How to attach OCL constraints to metamodels (e.g. via stereotypes) used to vary from tool to tool.
For your project, using the Eclipse Papyrus project should suffice, which should support what you need.
In Papyrus, you can also try out OCL queries in the console on the current UML model before you store them in the profile.
2 part question... I have several resource files (.resx) used in my solution primarily for translation of strings. For example, Errors.resx, Validation.resx, and Enums.resx.
Part1 : If I didn't have the Enums resource file, I'd assume that I should place all resource files in the UI Layer, probably within it's own assembly (like 'Company.App1.MVCApp.Resources') and reference it from the web app (Company.App1.MVCApp)... would I be correct in placing the resource files in the UI layer?
Part 2: The Enums.resx file contains descriptive strings that tie to enum members (using the Description attribute), in my UI and sometimes Domain services I will need to access the descriptive strings possibly in their translation. I thought about storing this somewhere in the Core/Domain layer maybe somewhere like Company.App1.Core.Resources ... ? Or should I create an abstraction in the Core layer and then implement the ResourcemManager somewhere in the Infrastructure layer in order to stick to the proper Onion Architecture.. ?
Part1 : In the application I'm currently working on, there isn't one resx file per concern (Enums, Errors...) but one resx file per project. If you take error messages, for instance, purely UI error messages go in the UI resx file, domain error messages go in the Domain resx, and son on. IMO resource files are best placed closest to the code where the localized strings are used. Having most localization files in the UI project tightly couples localization to the way your application is rendered, which might be problematic if you want to reuse localization in another context than that of your main UI.
Part2 : If you only need to access localized enum members in the Domain layer, then you could have a specific helper in the domain layer that derives from or uses System.Resources.ResourceManager to find the localized string. However, I find it handy to have some kind of general-purpose localization helper in an independent layer that centralizes all the localization logic that is more complex than just a Properties.Resources.[...] and is able to search in all resx files of your solution if need be.
I'm facing several problems trying to apply DDD with EF4 (in ASP MVC2 context). Your advaice would be greatly appreciated.
First of all, I started to use POCO because the dependacy on ObjectContext was not very comfortable in many situations.
Going to POCO solved some problems but the experience is not what I was used to with NHibernate.
I would like to know if it's possible to use designer and to generate not only entities but also a Value Objects (ComplexType?). If I mean Value Object is a class with one ctor without any set properties (T4 modification needed ?).
The only way I found to add behavior to anemic entities is to create partial classes that extends those generated by edmx. I'm not satisfied with this approach.
I don't know how to create several repositories with one edmx. For now I'm using a partial classes to group methods for each aggregate. Each group is a repository in fact.
The last question is about IQueryable. Should it be exposed outside the repository ? If I refer to the ble book, the repository should be a unit of execution and shouldn't expose something like IQueryable. What do you think ?
Thanks for your help.
Thomas
It's fine to use POCOs, but note that EntityObject doesn't require an ObjectContext.
Yes, Complex Types are value objects and yes, you can generate them in the designer. Select several properties of an entity, right click, and choose refactor into complex type.
I strongly recommend putting business methods in their own types, not on entities. "Anemic" types can be a problem if you must maintain them, but when they're codegened they're hardly a maintenance problem. Making business logic separate from entity types allows your business rules and your data model to evolve independently. Yes, you must use partial classes if you must mix these concerns, but I don't believe that separating your model and your rules is a bad thing.
I think that repositories should expose IQueryable, but you can make a good case that domain services should not. People often try to build their repositories into domain services, but remember that the repository exists only to abstract away persistence. Concerns like security should be in domain services, and you can make the case that having IQueryable there gives too much power to the consumer.
I think it's OK to expose IQueryable outside of the repository, only because not doing so could be unnecessarily restrictive. If you only expose data via methods like GetPeopleByBirthday and GetPeopleByLastName, what happens when somebody goes to search for a person by last name and birthday? Do you pull in all the people with the last name "Smith" and do a linear search for the birthday you want, or do you create a new method GetPeopleByBirthdayAndLastName? What about the poor hapless fellow who has to implement a QBE form?
Back when the only way to make ad hoc queries against the domain was to generate SQL, the only way to keep yourself safe was to offer just specific methods to retrieve and change data. Now that we have LINQ, though, there's no reason to keep the handcuffs on. Anybody can submit a query and you can execute it safely without concern.
Of course, you could be concerned that a user might be able to view another's data, but that's easy to mitigate because you can restrict what data you give out. For example:
public IQueryable<Content> Content
{
get { return Content.Where(c => c.UserId == this.UserId); }
}
This will make sure that the only Content rows that the user can get are those that have his UserId.
If your concern is the load on the database, you could do things like examine query expressions for table scans (accessing tables without Where clauses or with no indexed columns in the Where clause). Granted, that's non-trivial, and I wouldn't recommend it.
It's been some time since I asked that question and had a chance to do it on my own.
I don't think it's a good practice to expose IQueryable at all outside the DAL layer. It brings more problems that it solves. I'm talking about large MVC applications. First of all the refactorings is harder, many developers user IQueryable instances from the views and after struggle with the fact that when resolving IQueryable the connection was already disposed. Performance problems because all the database is often queried for a given set of resultats and so on.
I rather expose Ienumerable from my repositories and believe me, it saves me many troubles.
What would be the easiest way to add a new field to a list of potential fields on an existing ldap schema?
How would this affect existing records?
The field would be added at the deepest level of the dn (each user account).
Typically you can extend the schema of the LDAP server. Specific details depend on the underlying service providing the LDAP. (Active Directory is slightly different than eDirectory, and slightly different than in OpenLDAP or SunOne).
However, common to all those possible LDAP servers is the concept of an Auxiliary Class.
The base schema that comes with the server usually has Structural classes which are ones you can really use for objects. Another is Abstract classes, which are really just placeholders, so that you can have other classes (Say a structural class) inherit from it. Perhaps two Structural classes might inherit from the same abstract class, thus making definitions easier and cleaner.
Finally we come to Auxiliary classes which are probably the most useful. These classes cannot stand on their own, but you can add the class name to the Object Class (objectClass) attribute list, and then the additional attributes defined in the Aux class can be used.
This is the safest, least painful way to extend an LDAP Schema. It does not touch Base schema, nor any of the standard shipping classes. Rather, you have a completely standalone class that you can add to any object you would like, and it is easy to modify.