I have two entities Foo and Bar with a Many to Many relationship between them.
Let's say there is no semantic argument for why Foo might be "responsible" for the many to many relationship, but we arbitrarily decide that Foo is responsible for the relation (I.e., in NHibernate we would mark Bar as Inverse)
That's all well and good from a DB perspective, but my entity APIs reveal a problem.
// Responsible for the relation
public class Foo
{
List<Bar> Bars = new List<Bar>();
public void AddBar(Bar bar)
{
Bars.Add(bar);
bar.AddFoo(this);
}
}
public class Bar
{
List<Foo> Foos = new List<Foo>();
// This shouldn't exist.
public void AddFoo(Foo foo)
{
Foos.Add(foo);
foo.AddBar(this); // Inf Recursion
}
}
If we've decided that Foo is responsible for this relationship, how do I update the associated collection in Bar without creating a public Bar.AddFoo() method which shouldn't even exist?
I feel like I should be able to maintain the integrity of my domain model without resorting to having to reload these entities from the DB after an operation such as this.
UPDATE: Code tweak inspired by commenter.
You might be missing a domain concept there. Have you tried creating a third entity: FooBarRelationship?
See Working bi-directional links in the Hibernate documentation.
Many developers program defensively
and create link management methods to
correctly set both sides, e.g. in
Person:
protected Set getEvents() {
return events;
}
protected void setEvents(Set events) {
this.events = events;
}
public void addToEvent(Event event) {
this.getEvents().add(event);
event.getParticipants().add(this);
}
public void removeFromEvent(Event event) {
this.getEvents().remove(event);
event.getParticipants().remove(this);
}
I personally think Entity object holding the list of related object is being too smart, and you should let the DAL hit the database.
DALFactory.FooAdapter.getBars(foo);
You said that one side will "own" the relationship. Make this method public. The other associations (or add methods) can be made internal to avoid consumers from interacting with it directly.
public class Foo
{
private IList<Bar> Bars {get;set;}
public void AddBar(Bar bar)
{
Bars.Add(bar);
bar.Foos.Add(this);
}
}
public class Bar
{
internal IList<Foo> Foos {get;set;}
}
you could make it static
public class Foo
{
List<Bar> Bars = new List<Bar>();
public void AddBar(Bar bar)
{
Bars.Add(bar);
Bar.AddFoo(bar,this);
}
}
public class Bar
{
List<Foo> Foos = new List<Foo>();
// This shouldn't exist.
public static void AddFoo(Bar bar, Foo foo)
{
bar.Foos.Add(foo);
//foo.AddBar(this); inf recurtion
}
}
Not really ideal but it does get the function off the object its self
Related
Suppose I have a game, where there are buildings sorted by type. Each type is represented as a separate class, but sometimes I have to do some uncommon logic for the buildings of the same type. How could one implement this kind of behaviour?
For example, I can identify buildings by ID, so I can have a giant switch or command pattern inside the building type class. But I think that something is not right with this approach.
Another approach is to have different class for any divergent logic. But this proposes a lot of small classes.
This is what polymorphism aims to solve, and one of the big differences between procedural and oop programming. You can achieve it through extending a base class, or by implementing an interface. Here is extending a base class:
public abstract class Building {
abstract void destroy();
}
public BrickBuilding extends Building {
#Override
public void destroy() {
bricks.fallToGround();
}
}
public HayBuilding extends Building {
#Override
public void destroy() {
straw.blowInWind();
}
}
In places in your code where you would have used a switch statement to switch on building type, just hold a reference to the abstract Building type, and call method destroy() on it:
public class BuildingDestroyer {
public void rampage() {
for(Building building : allTheBuildings) {
// Could be a BrickBuilding, or a HayBuilding
building.destroy();
}
}
}
Or, to address your concern about having a lot of small types, you can 'inject' a destroy behaviour you want into a common building type, like so...albeing, you will end up with a lot of different destroy behaviour classes too...so, this might not be a solution.
public interface DestroyBehaviour {
void destroy(Building building);
}
public class Building {
private int id;
public DestroyBehaviour destroyBehaviour;
public Building(int id, DestroyBehaviour destroyBehaviour) {
this.id = id;
this.destroyBehaviour = destroyBehaviour;
}
public void destroy() {
destroyBehaviour.destroy(this); // or something along those lines;
}
}
You can get rid of the giant switch by having a BuildingFactory class which exposes a registerBuildingType(typeName, instanceCreatorFunc) method, that each building class calls (from a static initialize method for example) and that gets called with a unique string for that class (class name would suffice) and a static "create" method that returns a new instance.
This approach also has the advantage of being able to load new buildings from dynamically linked libraries.
I have a base abstract class, which aggregates a bunch of items in a collection:
abstract class AMyAbstract
{
List<string> Items { get; private set; }
public AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items);
}
}
There are a lot of subclasses, let's name them Foo, Bar, Baz, etc. They all are immutable. Now I need a merge() method, which will merge items of two objects like this:
abstract class AMyAbstract
{
// ...
public AMyAbstract merge(AMyAbstract other)
{
// how to implement???
}
}
Foo foo1 = new Foo(new string[] {"a", "b"});
Bar bar1 = new Bar(new string[] {"c", "d"});
Foo fooAndBar = foo1.merge(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Since the objects are immutable, the merge() method should not change the state of items field, but instead it should return a new object of the class uppon which it is called. My question is: how to judiciously implement the merge() method?
Problem 1: AMyAbstract is clearly not aware of specific constructors of the subclasses (dependency inversion principle), thus I cannot (or can I?) create instance of the sub class in a super class.
Problem 2: Implementing merge() method in each of the subclasses is a lot of code repetition (DRY rule).
Problem 3: Extracting the merge() logic to a entirely new class does not solve the DRY rule problem. Even using the visitor pattern it is a lot of copy/paste.
The problems presented above rule out any idea of implementation I might have had before I read about SOLID. (my life has been miserable since then ;)
Or is there an entirely different, out-of-the-box approch to achieve the merge of such objects?
I'd appreciate answer in C#, Java or even PHP.
EDIT: I think I left out a piece of valid information: event though there are a lot of different sub classes, they can (should) only be constructed in two, maybe three ways (as an implication of the single responsibility principle):
parameterless constructor
a constructor which accepts one IEnumerable<T> argument
a constructor which accepts array and some other modifier
This would put the visitor pattern back on the tablie if I could put a constraint on the constructors - for example by defining a constructor in an interface. But this is possible only in PHP. In Java or C# a constructor signature cannot be enforced, thus I cannot be certain of how I would instantiate a subclass. This is a good rule in general, because one could never predict of how author of the subclass would like the object be constructed, but in this particular case it might have been helpful. So a helper question would be: can I somehow enforce how a class is instantiated? Builder pattern sounds like way too much in this simple case, or does it?
You are right about dependency inversion rule and code duplication problems.
You can write the core implementation of the merge logic in your abstract class and give out the task of creating a new instance to the derived classes. Create an abstract method in your abstract class that will force all the children to implement it. The purpose is this method is to create a new instance of the class and return it. This method will be used by the super class to get a new instance and do the merging.
The resultant java code will look something like this
abstract class AMyAbstract {
// ...
public AMyAbstract merge(AMyAbstract other) {
AMyAbstract obj = getNewInstance();
// Do the merge
// Return the merged object.
}
protected abstract AMyAbstract getNewInstance();
}
class foo extends AMyAbstract {
protected foo getNewInstance() {
// Instantiate Foo and return it.
}
}
Hope this helps..
OBSOLETE, kept for reference (and shows how I arrived at the final solution), see code after EDIT below
I would say the builder pattern is the way to go. We just need a builder which keeps the instance but modifies the one field that needs to be changed.
If one wants to obtain (as shown in your code)
Foo fooAndBar = foo1.merge(bar1);
an additional generic type definition is needed (thus defining class AMyAbstract <T>) to be able to still produce the correct final type (instead of just seeing AMyAbstract as type for the fooAndBar) in the above call.
Note: merge method was renamed to MergeItems in the code below to make clear what is merged.
I specified different constructors for Foo and Bar, so that it is clear that they do not need to have the same number of parameters.
Actually to be truly immutable, the list should not be directly returned in the Items property as it could be modified by the caller (using new List(items).AsReadOnly() produced a ReadOnlyCollection, so I just used this one).
Code:
abstract class AMyAbstract<T> where T : AMyAbstract<T>
{
public ReadOnlyCollection<string> Items { get; private set; }
protected AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items).AsReadOnly();
}
public T MergeItems<T2>(AMyAbstract<T2> other) where T2 : AMyAbstract<T2>
{
List<string> mergedItems = new List<string>(Items);
mergedItems.AddRange(other.Items);
ButWithItemsBuilder butWithItemsBuilder = GetButWithItemsBuilder();
return butWithItemsBuilder.ButWithItems(mergedItems);
}
public abstract class ButWithItemsBuilder
{
public abstract T ButWithItems(List<string> items);
}
public abstract ButWithItemsBuilder GetButWithItemsBuilder();
}
class Foo : AMyAbstract<Foo>
{
public string Param1 { get; private set; }
public Foo(IEnumerable<string> items, string param1)
: base(items)
{
this.Param1 = param1;
}
public class FooButWithItemsBuilder : ButWithItemsBuilder
{
private readonly Foo _foo;
internal FooButWithItemsBuilder(Foo foo)
{
this._foo = foo;
}
public override Foo ButWithItems(List<string> items)
{
return new Foo(items, _foo.Param1);
}
}
public override ButWithItemsBuilder GetButWithItemsBuilder()
{
return new FooButWithItemsBuilder(this);
}
}
class Bar : AMyAbstract<Bar>
{
public string Param2 { get; private set; }
public int Param3 { get; private set; }
public Bar(IEnumerable<string> items, string param2, int param3)
: base(items)
{
this.Param2 = param2;
this.Param3 = param3;
}
public class BarButWithItemsBuilder : ButWithItemsBuilder
{
private readonly Bar _bar;
internal BarButWithItemsBuilder(Bar bar)
{
this._bar = bar;
}
public override Bar ButWithItems(List<string> items)
{
return new Bar(items, _bar.Param2, _bar.Param3);
}
}
public override ButWithItemsBuilder GetButWithItemsBuilder()
{
return new BarButWithItemsBuilder(this);
}
}
class Program
{
static void Main()
{
Foo foo1 = new Foo(new[] { "a", "b" }, "param1");
Bar bar1 = new Bar(new[] { "c", "d" }, "param2", 3);
Foo fooAndBar = foo1.MergeItems(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Console.WriteLine(String.Join(", ", fooAndBar.Items));
Console.ReadKey();
}
}
EDIT
Perhaps a simpler solution would be to avoid the builder class, and instead have
abstract T ButWithItems(List<string> items);
directly in the base class, and implementing classes would just implement it as currently the builders do.
Code:
abstract class AMyAbstract<T> where T : AMyAbstract<T>
{
public ReadOnlyCollection<string> Items { get; private set; }
protected AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items).AsReadOnly();
}
public T MergeItems<T2>(AMyAbstract<T2> other) where T2 : AMyAbstract<T2>
{
List<string> mergedItems = new List<string>(Items);
mergedItems.AddRange(other.Items);
return ButWithItems(mergedItems);
}
public abstract T ButWithItems(List<string> items);
}
class Foo : AMyAbstract<Foo>
{
public string Param1 { get; private set; }
public Foo(IEnumerable<string> items, string param1)
: base(items)
{
this.Param1 = param1;
}
public override Foo ButWithItems(List<string> items)
{
return new Foo(items, Param1);
}
}
class Bar : AMyAbstract<Bar>
{
public string Param2 { get; private set; }
public int Param3 { get; private set; }
public Bar(IEnumerable<string> items, string param2, int param3)
: base(items)
{
this.Param2 = param2;
this.Param3 = param3;
}
public override Bar ButWithItems(List<string> items)
{
return new Bar(items, Param2, Param3);
}
}
class Program
{
static void Main()
{
Foo foo1 = new Foo(new[] { "a", "b" }, "param1");
Bar bar1 = new Bar(new[] { "c", "d" }, "param2", 3);
Foo fooAndBar = foo1.MergeItems(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Console.WriteLine(String.Join(", ", fooAndBar.Items));
Console.ReadKey();
}
}
I'm a bit late to the party but as you have yet to accept an answer I thought I would add my own.
One of the key points is that the collection should be immutable. In my example I have exposed IEnumerable to facilitate this - the collection of items is immutable outside of the instance.
There are 2 ways I see this working:
a public default constructor
an internal Clone template method similar to #naveen's answer above
Option 1 is less code but really it depends whether an instance of AMyAbstract with no items and no way to change the items is something you want to allow.
private readonly List<string> items;
public IEnumerable<string> Items { get { return this.items; } }
public static T CreateMergedInstance<T>(T from, AMyAbstract other)
where T : AMyAbstract, new()
{
T result = new T();
result.items.AddRange(from.Items);
result.items.AddRange(other.Items);
return result;
}
Seems to satisfy all of your requirements
[Test]
public void MergeInstances()
{
Foo foo = new Foo(new string[] {"a", "b"});
Bar bar = new Bar(new string[] {"c", "d"});
Foo fooAndBar = Foo.CreateMergedInstance(foo, bar);
Assert.That(fooAndBar.Items.Count(), Is.EqualTo(4));
Assert.That(fooAndBar.Items.Contains("a"), Is.True);
Assert.That(fooAndBar.Items.Contains("b"), Is.True);
Assert.That(fooAndBar.Items.Contains("c"), Is.True);
Assert.That(fooAndBar.Items.Contains("d"), Is.True);
Assert.That(foo.Items.Count(), Is.EqualTo(2));
Assert.That(foo.Items.Contains("a"), Is.True);
Assert.That(foo.Items.Contains("b"), Is.True);
Assert.That(bar.Items.Count(), Is.EqualTo(2));
Assert.That(bar.Items.Contains("c"), Is.True);
Assert.That(bar.Items.Contains("d"), Is.True);
}
Whether you ultimately choose a default constructor or a template method the crux of this answer is that the Items only need to be immutable on the outside.
A neat solution based on #AK_'s comment:
tldr: The basic idea is to create a multiple merge methods for each aggregated filed instead of using a merge method for entire object.
1) we'd want a special list type for the purpose of aggregating the items inside AMyAbstract instances, so let's create one:
class MyList<T> extends ReadOnlyCollection<T> { ... }
abstract class AMyAbstract
{
MyList<string> Items { get; private set; }
//...
}
The advantage here is that we have a specialized list type for our purpose, which we can alter later.
2) instead of having a merge method for entire object of AMyAbstract we would want to use a method which merly merges the items of that object:
abstract class AMyAbstract
{
// ...
MyList<T> mergeList(AMyAbstract other)
{
return this.Items.Concat(other.Items);
}
}
Another advatage we gain: decomposition of the problem of merging entire object. So instead we break it into a small problems (merging just the aggregated list in this case).
3) and now we can create a merged object using any specialized constructor we might think of:
Foo fooAndBar = new Foo(foo1.mergeList(bar1));
Instead of returning the new instance of entire object we return only the merged list, which in turn can be used to create object of target class. Here we gain yet another advantage: deferred object instantiation, which is the main purpose of creational patterns.
SUMMARY:
So not only this solution solves the problems presended in the question, but provides additional advantages presented above.
I started working with PrintDocument object in WinForms in order to do some printing.
I noticed something very strange about that object.
In it there is a property called DefaultPageSettings, and in that property their is a property called PrinterSettings an so on.
I can write:
PrintDocumet.DefaultPageSettings.PrinterSettings.DefaultPageSettings.PrinterSettings.DefaultPageSettings.PrinterSettings
and continue forever without getting into a NULL object.
Can someone please explain why is this?
This is very simple crossreference really, you can easily build it by having two objects that refer to each other. It's not necessarily a good idea, but sometimes design ideals (like it may cost too much to redesign an old application to behave more reasonably in reference to the new one you're building) drive you into a situation where you're just stuck with it.
public class Foo {
private Bar bar;
public Foo(Bar bar) {
this.bar = bar;
}
public Bar getBar() {
return bar;
}
}
public class Bar {
private Foo foo;
public void setFoo(Foo foo) {
this.foo = foo;
}
public void getFoo() {
return foo;
}
}
public class FooBarTest {
public static void main (String[] args) {
Foo foo = new Foo();
Bar bar = new Bar(foo);
foo.setBar(bar);
foo.getBar().getFoo().getBar().getFoo()...
}
}
I have spent the last day trying to work out which pattern best fits my specific scenario and I have been tossing up between the State Pattern & Strategy pattern. When I read examples on the Internet it makes perfect sense... but it's another skill trying to actually apply it to your own problem. I will describe my scenario and the problem I am facing and hopefully someone can point me in the right direction.
Problem: I have a base object that has different synchronization states: i.e. Latest, Old, Never Published, Unpublished etc. Now depending on what state the object is in the behaviour is different, for example you cannot get the latest version for a base object that has never been published. At this point it seems the State design pattern is best suited... so I have implemented it and now each state has methods such as CanGetLatestVersion, GetLatestVersion, CanPublish, Publish etc.
It all seems good at this point. But lets say you have 10 different child objects that derive from the base class... my solution is broken because when the "publish" method is executed for each state it needs properties in the child object to actually carry out the operation but each state only has a reference to the base object. I have just spent some time creating a sample project illustrating my problem in C#.
public class BaseDocument
{
private IDocumentState _documentState;
public BaseDocument(IDocumentState documentState)
{
_documentState = documentState;
}
public bool CanGetLatestVersion()
{
return _documentState.CanGetLatestVersion(this);
}
public void GetLatestVersion()
{
if(CanGetLatestVersion())
_documentState.CanGetLatestVersion(this);
}
public bool CanPublish()
{
return _documentState.CanPublish(this);
}
public void Publish()
{
if (CanPublish())
_documentState.Publish(this);
}
internal void Change(IDocumentState documentState)
{
_documentState = documentState;
}
}
public class DocumentSubtype1 : BaseDocument
{
public string NeedThisData { get; set; }
}
public class DocumentSubtype2 : BaseDocument
{
public string NeedThisData1 { get; set; }
public string NeedThisData2 { get; set; }
}
public interface IDocumentState
{
bool CanGetLatestVersion(BaseDocument baseDocument);
void GetLatestVersion(BaseDocument baseDocument);
bool CanPublish(BaseDocument baseDocument);
bool Publish(BaseDocument baseDocument);
SynchronizationStatus Status { get; set; }
}
public class LatestState : IDocumentState
{
public bool CanGetLatestVersion(BaseDocument baseDocument)
{
return false;
}
public void GetLatestVersion(BaseDocument baseDocument)
{
throw new Exception();
}
public bool CanPublish(BaseDocument baseDocument)
{
return true;
}
public bool Publish(BaseDocument baseDocument)
{
//ISSUE HERE... I need to access the properties in the the DocumentSubtype1 or DocumentSubType2 class.
}
public SynchronizationStatus Status
{
get
{
return SynchronizationStatus.LatestState;
}
}
}
public enum SynchronizationStatus
{
NeverPublishedState,
LatestState,
OldState,
UnpublishedChangesState,
NoSynchronizationState
}
I then thought about implementing the state for each child object... which would work but I would need to create 50 classes i.e. (10 children x 5 different states) and that just seems absolute crazy... hence why I am here !
Any help would be greatly appreciated. If it is confusing please let me know so I can clarify!
Cheers
Let's rethink this, entirely.
1) You have a local 'Handle', to some data which you don't really own. (Some of it is stored, or published, elsewhere).
2) Maybe the Handle, is what we called the 'State' before -- a simple common API, without the implementation details.
3) Rather than 'CanPublish', 'GetLatestVersion' delegating from the BaseDocument to State -- it sounds like the Handle should delegate, to the specific DocumentStorage implementation.
4) When representing external States or Storage Locations, use of a separate object is ideal for encapsulating the New/Existent/Deletion state & identifier, in that storage location.
5) I'm not sure if 'Versions' is part of 'Published Location'; or if they're two independent storage locations. Our handle needs a 'Storage State' representation for each independent location, which it will store to/from.
For example:
Handle
- has 1 LocalCopy with states (LOADED, NOT_LOADED)
- has 1 PublicationLocation with Remote URL and states (NEW, EXIST, UPDATE, DELETE)
Handle.getVersions() then delegates to PublicationLocation.
Handle.getCurrent() loads a LocalCopy (cached), from PublicationLocation.
Handle.setCurrent() sets a LocalCopy and sets Publication state to UPDATE.
(or executes the update immediately, whichever.)
Remote Storage Locations/ Transports can be subtyped for different methods of accessing, or LocalCopy/ Document can be subtyped for different types of content.
THIS, I AM PRETTY SURE, IS THE MORE CORRECT SOLUTION.
[Previously] Keep 'State' somewhat separate from your 'Document' object (let's call it Document, since we need to call it something -- and you didn't specify.)
Build your heirarchy from BaseDocument down, have a BaseDocument.State member, and create the State objects with a reference to their Document instance -- so they have access to & can work with the details.
Essentially:
BaseDocument <--friend--> State
Document subtypes inherit from BaseDocument.
protected methods & members in Document heirarchy, enable State to do whatever it needs to.
Hope this helps.
Many design patterns can be used to this kind of architecture problem. It is unfortunate that you do not give the example of how you do the publish. However, I will state some of the good designs:
Put the additional parameters to the base document and make it
nullable. If not used in a document, then it is null. Otherwise, it
has value. You won't need inheritance here.
Do not put the Publish method to the DocumentState, put in the
BaseDocument instead. Logically, the Publish method must be part
of BaseDocument instead of the DocumentState.
Let other service class to handle the Publishing (publisher
service). You can achieve it by using abstract factory pattern. This
way, you need to create 1:1 document : publisher object. It may be
much, but you has a freedom to modify each document's publisher.
public interface IPublisher<T> where T : BaseDocument
{
bool Publish(T document);
}
public interface IPublisherFactory
{
bool Publish(BaseDocument document);
}
public class PublisherFactory : IPublisherFactory
{
public PublisherFactory(
IPublisher<BaseDocument> basePublisher
, IPublisher<SubDocument1> sub1Publisher)
{
this.sub1Publisher = sub1Publisher;
this.basePublisher = basePublisher;
}
IPublisher<BaseDocument> basePublisher;
IPublisher<SubDocument1> sub1Publisher;
public bool Publish(BaseDocument document)
{
if(document is SubDocument1)
{
return sub1Publisher.Publish((SubDocument1)document);
}
else if (document is BaseDocument)
{
return basePublisher.Publish(document);
}
return false;
}
}
public class LatestState : IDocumentState
{
public LatestState(IPublisherFactory factory)
{
this.factory = factory;
}
IPublisherFactory factory;
public bool Publish(BaseDocument baseDocument)
{
factory.Publish(baseDocument);
}
}
Use Composition over inheritance. You design each interface to each state, then compose it in the document. In summary, you can has 5 CanGetLatestVersion and other composition class, but 10 publisher composition class.
More advancedly and based on the repository you use, maybe you can use Visitor pattern. This way, you can has a freedom to modify each publishing methods. It is similiar to my point 3, except it being declared in one class. For example:
public class BaseDocument
{
}
public class SubDocument1 : BaseDocument
{
}
public class DocumentPublisher
{
public void Publish(BaseDocument document)
{
}
public void Publish(SubDocument1 document)
{
// do the prerequisite
Publish((BaseDocument)document);
// do the postrequisite
}
}
There may be other designs available but it is dependent to how you access your repository.
I have the following idea:
Business object implemented as interface or abstract class with certain properties as read only to all layers except the DAL layer. I also want my business objects in another assembly than the DAL (for testing purposes), so marking the properties is not an option for me.
Examples could be one to one relationships or other properties.
I have almost solved the issue by doing the following
abstract class User
{
public virtual long UserId {get; protected set;}
public virtual string Password {get; protected set;}
...
}
In the DAL:
public class DbUser : User
{
internal virtual void SetPassword(string password) {...}
}
I then map this using fluent as
ClassMap<User> {...}
SubclassMap<DbUser> {...}
The problem I get is that fluent tries to create a table named DbUser.
If I skip the SubclassMap and creates a DbUser object and tries to save it I get an "No persister for this object" error.
Is it possible to solve?
You could probably override what is done with Fluent
public class DbUser: IAutoMappingOverride<DbUser>
{
public void Override(AutoMapping<DbUser> mapping)
{
//tell it to do nothing now, probably tell it not to map to table,
// not 100% on how you'd do this here.
}
}
Or you could have an attribute
public class DoNotAutoPersistAttribute : Attribute
{
}
And in AutoPersistenceModelGenerator read for attribute in Where clause to exclude it.
Check would be something like
private static bool CheckPeristance(Type t) {
var attributes = t.GetCustomAttributes(typeof (DoNotAutoPersistAttribute), true);
Check.Ensure(attributes.Length<=1, "The number of DoNotAutoPersistAttribute can only be less than or equal to 1");
if (attributes.Length == 0)
return false;
var persist = attributes[0] as DoNotAutoPersistAttribute;
return persist == null;
}
Then it kind of depends how you're adding entities but you're probably adding via assembly so this might do it for you:
mappings.AddEntityAssembly(typeof(User).Assembly).Where(GetAutoMappingFilter);
....
...
private static bool GetAutoMappingFilter(Type t)
{
return t.GetInterfaces().Any(x => CheckPeristance(x)); //you'd probably have a few filters here
}