I remember reading once (I believe the book was the .NET Framework Design Guidelines) that when you are designing a framework or class library that you should take care in how you arrange the classes in your namespaces. Specifically, classes in parent namespaces should have no knowledge of classes in child namespaces. Conversely, it is perfectly alright for classes in the child namespaces to know about the classes in namespaces above them.
For example, the classes in the System namespace don't know anything about the classes in the System.Data.SqlClient namespace. However, classes in System.Data.SqlClient know about the classes in System and in System.Data.
Now, taken at face value, this is a pretty straightforward idea. But there are occasions where this isn't as easy to implement as you might think. Classes are inherently coupled to one another by their very nature. For example:
A business class
The data entity class
The class that maps a data entity class to a business object class
The classes that serialize the data entity to and from the database
Granted, you can separate these into separate, discrete classes that clearly isolate the data and functionality; that isn't my problem. My problem is how to properly arrange them into namespaces that observe best practices for namespaces.
This has always seemed a bit murky to me. I've never seen it clearly addressed, and most samples I've seen have simply placed the data objects off the root namespace (MyProject.DataObjects) or something similar. It's as if noone is really sure, so we just don't talk about it.
I can see that, within the .NET Framework itself, classes reach across namespace boundaries all the time to access the functionality they need. Classes frequently access functionality from System.Collections, System.Collections.Generic, System.Runtime, System.Configuration, System.Reflection, and so on.
It's as if there's an unspoken rule that states that, when it comes to namespaces, "You can't know anything about your own children, but you can know all there is to know about the children of your grandparents, aunts, uncles, neices, nephews, and cousins." This guideline seems counter-intuitive and senseless to me; it seems to complicate namespace design.
So Here's the Question
How do you design namespaces in your own large applications? Are you really all that concerned about preserving namespace boundaries? If so, how do you resolve issues where classes are clearly related (despite having been decoupled as much as you can manage)?
I'm really interested in your experiences, and your input on this. It's been bugging me for a while now. If you could provide an example of namespace arrangement for a 3-tier application that included business objects, data entities, and so on, it'd be great. I'd really like to see how you guys arrived at your namespace models, and why.
Thanks very much in advance!
If you have two tightly inter-related classes, you just put them in the same namespace.
I see namespaces as being for holding related classes, functions, enums, etc., so this should be quite natural.
Now it might be the case that some namespaces naturally build on items in other namespaces. But if two classes are so closely related as to build on each other, I'm not sure why I would even consider putting them in different namespaces. There's probably a good reason, but I've never come across it.
Related
I am trying to build a domain model with business methods and have EF 4.1 doing the persistence for me. So far so good.
Problem is, all properties are exposed as public on my domain classes. That's at least what I learnt from the tutorial anyway. That means, I have no strong proof that class properties won't change by some careless programmers outside of business methods. Encapsulation violated.
I tried introducing ISomething but TableAttribute applies only to classes, not interfaces, so I can't tell EF to do DBSet. If I leave TableAttribute to classes but make Something implement ISomething anyway then I can't do DBSet.Add() because EF doesn't know ISomething.
The only way I can think of is write a complete abstraction layer on top of EF 4.1 for CRUD using interfaces. Under the hood, do the type translation between Something and ISomething. It sounded a lot of complexity and a gaping hole in EF's design. Or I must've missed something.
How would you solve this?
Many thanks.
Problem is, all properties are exposed as public on my domain classes.
That's at least what I learnt from the tutorial anyway. That means, I
have no strong proof that class properties won't change by some
careless programmers outside of business methods. Encapsulation
violated.
How this will be solved by interface? Interface will again expose all properties as public and EF demands that property must have getter and setter.
EF is not able to work with interfaces. When using EDMX for mapping it is possible to play little bit with properties' accessibility but when using code first it is much worse because mapping is affected by the same accessibility rules. Creating abstraction layer on top of EF is mostly same as not using EF at all. Once you create abstraction you cannot use linq-to-entities directly and you will lose main reason for using EF.
Your problem is more about: Where is the boundary? If you want to work with entities only in business methods you should not expose them from these methods. If you want to make sure that properties are correctly handled perhaps you should implement validation logic directly into the entity.
I have created a Singleton class that handles my project texts. What is the appropriate name of a Singleton class like this?
TextManager?
TextHandler?
TextController?
Is there a difference in meaning of these names?
UPDATE:
The class stores the project text as xml and have a method for returning the correct text.
function getText(uid : String) : String
I suppose it doesn't deal with adding/removing/... (-> managing) the texts (maybe just loading), so it isn't a "real" Manager.
It also doesn't "control" the texts (something "You're only accessible from ...", "Return another value for that key if ...").
The class provides you with texts.
I suppose it's some Kind of localized text provider, right?
So why don't you call it LocalizedTextProvider?
I usually call something like this
TextUtility
or
TextHelper
the problem with 'handler' is that it implies some sort of event handling. Same thing with 'Controller', it has meaning in a different context.
I believe Controller is 'reserved' for the MVC model but I may be wrong. TextHandler and TextManager may be better but at least at the place I work, 'Manager' in a service/class is generally discouraged since it is assumed that every class 'manages' something (this may just be culture-specific, though).
I'd vote for TextHandler out of those three. It may also depend slightly on your programming language.
This actually sounds like a service or repository to me...
TextService or TextRepository? TextModel?
But let me back up a bit... the Singleton pattern is a pretty bad way of accessing something like this. Just google "Singleton pattern problems" if you want to see what I am talking about. Plus, in AS3, you don't have private constructors so you can't implement the Singleton pattern in a pure way.
Instead, I really prefer composition via "Inversion of Control" (IoC) containers. There are plenty of them out there for ActionScript. They can be really lightweight but they decouple your components in a really elegant way.
Sorry to inject my thoughts here... ymmv :)
EDIT -- More on eliminating Singleton pattern
I have written about several strategies on eliminating singletons in your code. This article was written for C#, but all the same principles apply. In that article, I DON't talk explicitly about IoC containers.
Here is a pretty good article about IoC in Flex. In addition, several frameworks give you IoC capabilities:
Swiz
Robot Legs
fling
Cairngorm
flex-ioc
All three of the names you proposed can all be interpreted in the same way. Some people prefer handlers while others might say controllers... it really is a matter of semantics. Whatever convention you choose to adopt just be consistent. The common notion that you should capture though is that the class which you are describing is not doing anything. It should only be in charge of delegating, since that's what managers do to employees and controllers do in the classic MVC paradigm.
As I usually have Handler in the event/message handling context. Controller for actions and MVC stuff, I would go with something different:
TextResources.get(key)
I18n.get(key) (if your class is in fact used for internationalisation)
I usually reserve Helpers for classes allowing to simply transform some data into something to be used in the view.
TextCache? Sounds like you are just using it to store and retrieve data...
Why not : ProjectNameTexts
FooTexts.getInstance().getText('hello_world');
I currently put them in an interface folder but this wont help readability for people who do not know the code base no more than lumping all of your implementation classes in a folder called implementation.
How do you guys logically sort your project interfaces.
I assume you're talking about the kind of interfaces that classes implement in OO languages.
I'd say it's better to name the folder by function, if you really want to separate the interface from implementing classes - call the folder 'listeners' or whatever these interfaces represent. The fact they're interfaces (or abstract classes) should be obvious from the way they're named and used.
Then again, if it's not some form of a framework other people will use, but end up with an interface and a two or three implementing classes you write and leave them be, you might as well stick them all together in the same package. I don't think that making a package for a single class/interface does much for clarity.
Not part of the question but I'll write it anyway - I'm also not a fan of the "I" prefix for interfaces. If it's not obvious without it, then it could probably use a different name/structure.
Using Linq to SQL, and a DDD style Domain Layer with de-coupled repositories, does anyone have any good ideas on how to implement a specification pattern without bleeding L2S concerns up into the domain layer, that is still understandable? :)
We have complex business logic surrounding the selection of a set of transaction data, and would like those rules/specifications to be owned by the Domain. We've also done a good job of keeping our domain persistence ignorant.
This presents a problem, because in order to implement a Specification, the domain (as far as I can tell) needs to see the types being queried (L2S types).
Any ideas?
Also, nHibernate is out of the question for reasons I don't want to explain.. :)
Have you considered mapping your generic Specifications into an Expression tree that would translate into proper L2S syntax? It seems that is the main problem you are hitting here. The Specification pattern isn't the problem, but the mapping to L2S is.
Linq-To-Sql classes can be partial. This means that you can extend them by implementing a partial that implements a common interface. That Interface can be shared between layers without the "bleeding" problem you are describing. The rest is just the details of your "IsStatisfiedBy" which should be easy to encapsulate.
I recently had the same issue. Different pattern, but still LINQ to SQL (L2S). I tried two different ways to avoid the leakage.
First we tried using DTOs and a mapping layer. So we wrote super simple objects that had a one to one mapping to the tables. They were all decorated with L2S attributes. We then wrote a mapping layer to map the DTOs to our business objects. All of this was hidden via the Repository pattern from Doman Driven Design. So consumers of the business objects had no idea the L2S was under the hood.
Next, mostly for variety. We tried using the XML mapping features of L2S so the objects themselves needed no attributes. For collections we exposed IEnumerable instead of any of L2S collections. If you looked at the internals of the business classes you could still detect some usage of L2S (EntitySet or Ref). But consumers of the class had no idea. So some bits of leakage but nothing drastic.
In the end we stuck with the first pattern. The second worked and we could have replaced L2S without changing the interface of the business layer, but I was never happy with XML mapping. The first pattern had a much cleaner separation between the database and the business objects. It took more code. The first one also worked better for us because it allowed us to evolve the business objects differently than the tables. In the early days of the project the xml mapping worked because our objects were pretty much one to one with the tables.
So in the end we put a layer between L2S and the domain. It worked. It took more code, but it was really simple stuff. And it was all very testable.
If you want to avoid referencing Linq2Sql from your domain layer, you must work against interfaces that represent your entities instead of working with the actual entities themselves. You then need a mapping layer between your interfaces and your entities.
I've worked this way and found it to be a severe hindrance. I switched to NHibernate for new projects and for the older projects I simply stopped worrying about the domain referencing Linq2Sql entities directly. Overcoming that restriction is simply too much of a time-cost in my opinion.
All the web frameworks that I have seen mostly follow the OO paradigm. Are there any web frameworks in Python or Ruby which follow the FP style?
Like python itself, you'll probably find web frameworks in python that blend the functional and object oriented paradigms. Django is a great example. Django follows a model-view-controller design, which they label as model-template-view. The interesting thing is that the three layers operate very differently.
Model is object-oriented. It isn't necessary to make it a stellar example of everything OOP can be. You can be dirt simple with your models: you name it, extend a base model class, and declare a few properties. This, I think, is as it ought to be, and I'll be fascinated to learn of other frameworks that are significantly less object-oriented at the model-layer. Your database needs table declarations, and your site needs to generate rows of data. This is extremely analagous to Classes and Instances no matter how you look at it.
Template is not python. It's supposed to look as much like html as possible, with some pretty ways to insert data that gets passed to it.
View is very functional. It can be coerced into an OO paradigm, and it can rely on the models to do the heavy lifting if it wants. But at core there are function declarations that execute some action. These function declarations are passed as arguments to a url config function.
I happen to like this blend of paradigms because I believe it does what works well for each given level. Some might call it inconsistent; others might say that the distinction between between model and presentation logic should be as sharp as possible to emphasize the distinction.
If you don't care much for OOP but can function in python, this framework might work well for you. Unless you're trying to leverage the default admin interface. Then metaclasses and formsets will make your head a'splode.