I'm starting a new project and i've recently found castle project activerecord, which seems like a GREAT solution, but at the same time, it looks like something realy unconventional.
I was wondering, does this feeling comes from learning something new (and i should just get used to it) or is really bad practice?
Part of what felt weird to me about using ActiveRecord was having to inherit from ActiveRecordBase<T>, and having all those persistence methods on your object (Save and so forth).
But it turns out you don't have to! Instead of having, say:
[ActiveRecord]
class Customer : ActiveRecordBase<Customer> { }
You can just have
[ActiveRecord]
class Customer : inherit from whatever you want { }
and then use ActiveRecordMediator<Customer>. It has basically the same static methods that ActiveRecordBase<T> has, but this way you don't have to clutter your object model with them. If you don't need the various protected method event hooks in ActiveRecordBase<T>, this can make things simpler.
ActiveRecord is a design pattern first named by Martin Fowler in Patterns of Enterprise Application Architectures. It is fairly common and used extensively in the popular Ruby framework Rails.
It contrasts with the more usual style of development in the .Net world which is to use DAOs, and that perhaps explains why you're uneasy.
A suggestion: read the source code for some Ruby on Rails applications which are similar to your own projects, and evaluate how you like the design style that results from heavy use of ActiveRecord.
It's not a bad solution but it has it's downsides.
In Patterns of Enterprise Application Architecture Martin Fowler describes several ways of designing applications that are built on top of a database. These methods differ in the way the application is decoupled from the database. He also describes that more decoupling makes more complex applications possible. Active Record is described as a way to design simpler applications but for applications with more complex behaviour you need a Domain Model that is independent of the database and something like an object-relational mapper in between.
ActiveRecord works very well in Ruby, but it's not easily transferable to all languages. The central feat of AR is the metaphor of table=class, row=instance. This comes out quite elegant in Ruby, because classes are also objects. In other languages, classes are usually a special kind of construct, and then you have to go through all sorts of hoops to make it work like properly. This takes away some of the natural feel that it has in Ruby.
The mixture of the domain object with the service layer is the biggest bad practice (if you see that as a bad practice). You end up calling user.Save() which means if you want to change your ORM, you are reliant on this pattern. The 2 alternatives are a layer aka a set of facade classes to perform your CRUD operations, or to put this inside the domain object as something like
User.Service.Save(user);
If you're using .NET then ActiveRecord is obviously ActiveRecord based, Coolstorage, Subsonic and a few others.
No it's not bad practice. Even in .NET it's a fairly well established pattern now. SubSonic (http://subsonicproject.com) and LINQ to SQL also use the pattern.
Implementations of the pattern, such as Subsonic, are great for quickly and easily creating a data access layer that manages the CRUD for your application.
That doesn't mean it's a good solution for all systems. For large, complex systems you probably want to have less coupling to the data store.
I think ActiveRecord has not much to do with Castle and therefore, the answers to this question Does the ActiveRecord pattern follow/encourage the SOLID design principles? could be more enlightening to many.
Related
Personally, I think inheritance is a great tool, that, when applied reasonably, can greatly simplify code.
However, I seems to me that many modern tools dislike inheritance. Let's take a simple example: Serialize a class to XML. As soon as inheritance is involved, this can easily turn into a mess. Especially if you're trying to serialize a derived class using the base class serializer.
Sure, we can work around that. Something like a KnownType attribute and stuff. Besides being an itch in your code that you have to remember to update every time you add a derived class, that fails, too, if you receive a class from outside your scope that was not known at compile time. (Okay, in some cases you can still work around that, for instance using the NetDataContract serializer in .NET. Surely a certain advancement.)
In any case, the basic principle still exists: Serialization and inheritance don't mix well. Considering the huge list of programming strategies that became possible and even common in the past decade, I feel tempted to say that inheritance should be avoided in areas that relate to serialization (in particular remoting and databases).
Does that make sense? Or am messing things up? How do you handle inheritance and serialization?
There are indeed a few gotcha with inheritance and serialization. One is that it leads to an asymmetry between serialization/deserialization. If a class is subclassed, this will work transparently during serialization, but will fail during deserialization, unless the deserialization is made aware of the new class. That's why we have tags such as #SeeAlso to annotate data for XML serialization.
These problems are however not new about inheritance. It's frequently discussed under the terminology open/closed world. Either you consider you know the whole world and classes, or you might be in a case where new classes are added by third-parties. In a closed world assumption, serialization isn't much a problem. It's more problematic in an open world assumption.
But inheritance and the open world assumption have anyway other gotchas. E.g. if you remove a protected method in your classes and refactor accordingly, how can you ensure that there isn't a third party class that was using it? In an open world, the public and internal API of your classes must be considered as frozen once made available to other. And you must take great care to evolve the system.
There are other more technical internal details of how serialization works that can be surprising. That's for Java, but I'm pretty sure .NET has similarities. E.g. Serialization Killer, by Gilad Bracha, or Serialization and security manager bug exploit.
I ran into this on my current project and this might not be the best way, but I created a service layer of sorts for it and its own classes. I think it came out being named ObjectToSerialized translator and a couple of interfaces. Typically this was a one to one (the "object" and "serialized" had the exact same properties) so adding something to the interface would let you know "hey, add this over here too".
I want to say I had a IToSerialized interface with a simple method on it for generic purposes and used automapper for most of the conversions. Sure, it's a bit more code but hey whatever, it worked and doesn't gum up other things.
My goal is to have an app that is using WPF and is a 3 tier architecture. UI, BLL, and DAL...I'd like to use the MVVM but I'm not sure how that works with a 3 tier architecture or if it is something entirely different. So with that in mind, I have a few questions:
1) LINQtoSQL: I've read a lot online that say LINQ replaces your DAL and seen many articles that say this a bad idea. I'm thinking it's a bad idea, however, what do I put in here? What are the datatypes i am returning to the BLL? IQueryable? ObservableCollection? I have no clue.
2) The BLL: I'd like to make this a service that runs on a server, so that when I need to make a change I don't need to redeploy the whole app, I just need to restart the service. But, I'm not sure where to start on this.
3) With the BLL, I guess I'm confused on how the data is going through all the layers from the DAL all the way to the Interface.
I've done lots of research online, and have got bits and pieces of things, however I haven't seen anyone talk about a WPF application that is using MVVM with LINQ in the DAL using SQLMetal and a BLL thats running on a server. Can anyone point me in the right direction? or maybe a book to get?
Mike,
your question is really cool, I like it. Firstly, feel free to experiment a bit - each and every project is different, so there's no single rule, which fits everywhere. That's why I would suggest just leaving DAL to LINQ 2 SQL. this great tool will handle it, you don't have to worry. Secondly - you mentioned 3 Tier Architecture, but why isn't there place for the Model? Since all models are generated automatically (e.g. SQLMetal), you don't have to worry about mappings either. So, if you're not bored yet, let me answer all of your 3 questions:
Skip DAL and observe your project carefuly - if you have a feeling, that it's lacking this layer - add it (it will contain LINQ2SQL queries). And the second part - you can return whatever you wish, but it will be most convenient for you to use IEnumerable<> or IQueryable<> parametrized with your models.
My intuition tells me, that you're going to need WCF - in this case you should be able to wrap whole (yes, that's true) whole business logic in a nice Contract and implement however you wish.
This is the easiest one :) Since your BLL layer is actually an implementation of some Contract (Interface), you can design that Interface to provide you with all data you need. For example:
Contract/Interface:
IEnumerable<User> GetTallUsersOver40();
IEnumerable<User> GetShortUsersOver60();
...
And that 'all the layers' you were talking about shrink to a single LINQ2SQL query execution. If you need more logic - place it in this layer.
I want to use MVVM, what now? The answer is simpler than you think - just prepare your views and view models and simply consume your BLL Contract/Interface implementaion.
Please ask if you have further questions!
I'll try to provide some insight, though I'm not an expert, I've tackled these issues in the past.
LINQ to SQL is actually pretty good at what it's supposed to do - which is replace your DAL. But don't return an IQueriable upwards to your BLL, as that would enable (or at least hint to the possibility) the BLL to query your DB directly. You should transfer the data object to the BLL and let it construct a matching business object. Also note: LINQ in and of itself can be used in any layer (and in fact is one of the best features of C#). LINQ to SQL is the mechanism by which LINQ statements get transated to SQL queries.
BLL as a service is a natural choice. Provide an upward interface to the presentation layer (a WCF service is a good option here).
The BLL generates business objects based on data it receives from the DAL. In order to provide for good decoupling of layers, you should use different classes for your DAL and BLL objects. Don't create a dependency between your presentation layer and your data layer.
Great question. I don't think there is any one place that has all the answers. I had very similar questions when we were starting a new project. MVVM is really just a presentation pattern and doesn't care of all the details like you listed. Laurent Bugnion has a good framework that glues everything together as well.
LINQ2SQL is cool but can get cumbersome with the VS08 designers. Take a look at http://plinqo.com/ to use with CodeSmith to generate the DAL and I think it will even do the BLL with contracts as well. Another generating option is Oleg Sych T4 templates One issue we ran into with LINQ2SQL is the singular datacontext. If you don't need to be modular this isn't an issue.
I agree with what the others said about data contracts and look at what Plinqo can generate. It may save you a lot of time.
The data will work it's way up in objects usually. Like the others said make sure you keep a seem between all the layers so you don't have dependencies.
When you get to the MVVM part you will open a whole new can of worms. I don't think there are many or any books out on MVVM yet. It is still a somewhat new fad.
Great question, I'm on the nursery slopes of the WCF/WPF learning curve so I'm in a similar position to you. My 2 cents:
Haven't got into Linq to SQL, I'm old school and used to writing stored procedures and views. I'm currently using these to populate DTO classes - that is, classes with no methods, just properties to represent the data. I know I'm probably behind the curve on this.
Make your BLL a WCF service - put the service contract(s) and data contract(s) in their own assembly, you can then include this in your client, where they become your model, or part of it.
In your client application, include a reference to the assembly containing the service contracts and data contracts. The data contracts then become your model, your ViewModels can wrap these models and expose their properties (implement INotifyPropertyChanged for databinding).
I'm using the O'Reilly books Programming WCF Services, Learning WCF Services and Programming WPF which I'm finding pretty good. I don't know of any books specifically about MVVM but there's loads of stuff on the web.
I had a client ask for advice building a simple WPF LOB application the other day. They basically want a CRUD application for a database, with main purpose being as a WPF training project.
I also showed them Linq To SQL and they were impressed.
I then explained its probably not a good idea to use that L2S entities directly from their BLL or UI code. They should consider something like a Repository pattern instead.
At which point I could already feel the over-engineering alarm bells going off in their heads (and also in mine to some extent). Do they really need all that complexity for a simple CRUD application? (OK, its effectively functioning as a WPF training project for them but lets pretend it turns into a "real" app).
Do you ever think its acceptable to use L2S entities all through your application?
How difficult is it (from experience) to refactor to use another persistence framework later?
The way I see it, if the UI layer uses the L2S entities as a simple a POCO (without touching any L2S specific methods) then that should be really easy to refactor later on if need be.
They do need a way to centralize the L2S queries, so some sort of way to manage that is needed, even if they do use L2S entities directly. So in a way we are already pushing toward some aspects of DAL/DAO/Repository.
The main problem with Repo I can see is the pain of mapping between L2S entities and some domain model. And is it really worth it? You get quite a lot "for free" on L2S entities which I think would be hard to use once you map to another model.
Thoughts?
The only major drawback to using L2S entities all the way through is that your UI needs to know about and bind to the concrete entities. That means your UI knows your data layer. Not usually a good idea. You really want a layered approach for anything that has the potential to be serious.
That said, it's perfectly possible to use the LINQ-to-SQL entities themselves in a layered architecture without knowledge of the data layer: extract interfaces for the entities and bind to them instead.
Keep in mind that all L2S entities are partial classes. Create interfaces that reflect your entities (Refactor => Extract Interface is your friend here) and create partial class definitions of your entities that implement the interfaces. Put the interfaces themselves (and only the interfaces) in a separate .DLL that your UI and Business Layer reference. Have your Business Layer and Data Layer accept and emit these interfaces rather than the concrete versions of them. You can even have the interfaces implement INotifyPropertyChanging, since the L2S entities themselves implement those interfaces. And it all works peachy.
Then, when/if you need a different persistence framework, you have no pain at all in the BL or UI, only in the data layer -- which is where you want it.
Repositories are not a big deal. See here for a pretty good treatment of their use in ASP.NET MVC:
http://nerddinnerbook.s3.amazonaws.com/Part3.htm
Basically what we did for a project was that we had a Business layer that did all of the "LINQing" to L2S objects... in essence centralizing all querying to one layer via "Manager Objects" (I guess these are somewhat akin to repositories).
We did not use DTOs to map to L2S; as we didn't feel is was worth the effort in this project. Part of our logic was that as more and more ORMs support Iqueryable and similar syntax to L2S (e.g. entity framework), then it probably wouldn't be THAT bad to switch to a different ORM, so its not that bad of a sin, IMO.
Do you ever think its acceptable to use L2S entities all through your application?
That depends. If you do a short lived product you can get things easily wired up in a quick succession if you use L2S. But if you do a long lived product which you might have to maintain for a long duration, then you better think about a proper persistence layer.
How difficult is it (from experience) to refactor to use another persistence framework later?
If you use L2S in all your layers, well then you must not think about re-factoring them to use another persistence framework. This is exactly the advantage of using a framework like NHibernate or Entity Framework in your persistence layer , that though it requires a bit of extra effort upfront it will be easy to maintain in the long run
It sounds like you should be considering the ViewModel Pattern for WPF
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
I am developing a transactional application in .NET and would like to get some input on how to properly encapsulate database access so that:
I don't have connection strings all
over the place
Multiple calls to the same stored
procedure from different functions
or WORSE, multiple stored
procedures that are different by a
single column
I am interested in knowing if using an ORM like NHibernate is useful, as it may just add another layer of complexity to a rapidly changing data model, and artifacts need to be produced on a tight schedule.
I am more interested in methods or patterns OTHER than ORM packages.
There are at least two widely accepted design patterns used to encapsulate data access:
repository (DDD)
DAO (Data Access Object)
For the sake of completeness I suggest you these books:
Patterns of Enterprise Application Architecture (Fowler)
Domain Driven Design (Evans)
If, as it appears, this is an important project and the DAL is a major risk factor, get someone involved who has done it before. You're exactly right that there are too many ways to run off the rails by trying to get this right the first time without solid experience.
There are any number of patterns for accomplishing this, but I'd look for someone who has a simple set of well-defined patterns they are fully comfortable with.
as stated above, check out the repository and unit of work patterns. the books by fowler and evans are highly recommended. so is karl seguin's reader which gave me a cooler introduction to the just mentioned books. grab it at http://codebetter.com/blogs/karlseguin/archive/2008/06/24/foundations-of-programming-ebook.aspx
As Java Developer, i could suggest to read about jdbc templates, despite of it s'n not .NET you could learn how Spring framework encapsulates data access tier and get some ideas.
I am continuing to delve into Erlang. I am thinking of starting my next web project using Erlang, and at this stage the only thing I will really miss from Ruby on Rails is ActiveRecord.
Is there a good alternative technology for Erlang?
Update:
The closest I have come to a solution is to ErlyDB, a component of ErlyWeb.
ErlyDB is a database abstraction layer
generator for Erlang. ErlyDB combines
database metadata and user-provided
metadata to generate functions that
let you perform common data access
operations in an intuitive manner. It
also provides a single API for working
with different database engines
(although currently, only MySQL is
supported), letting you write portable
data access code.
Well, the major advantages of ActiveRecord (as I see it) are:
You can persist your objects in a relational database nearly transparently.
You can search the database by any attribute of your objects.
You can validate objects when persisting them.
You can have callbacks on deleting, updating, or inserting objects.
With Mnesia:
You can persist any Erlang data absolutely transparently.
Using pattern matching, you can search the database by any attribute of your data or their combination.
QLC gives you a nice query interface for cases when pattern matching isn't enough.
No solutions for validating and callbacks, however...
So, what else do you have in ActiveRecord that is lacking in Mnesia?
I don't think there really is at the time of this writing. That may be because the kinds of systems being written in erlang and the type of people writing them don't really call for Relational Databases. I see much more code using mnesia, CouchDB, Tokyo Cabinet and other such alternative database technologies.
That's not to say someone might not want to create something like active record. It's just hasn't really been a need yet. Maybe you will be the first? :-)
You might be interested in Chicago Boss's "BossRecords":
http://www.chicagoboss.org/api-record.html
They are quite explicitly modeled on the Active Record pattern, and use a lot of compiler magic to make the syntax squeaky clean. BossRecords support save/validate as well as has_many/belongs_to associations. Attributes in your data model are made available through generated functions (e.g. "Employee:first_name()").
Some googling reveals libs / clients / wrappers for Couchdb described "ActiveRecord like libraries like CouchFoo", and advise to steer clear:
http://upstream-berlin.com/2009/03/31/the-case-of-activerecord-vs-couchdb/
http://debasishg.blogspot.com/2009/04/framework-inertia-couchdb-and-case-of.html#
as to your comment on "not suited for web apps yet", I think the pieces are there: mochiweb, couch, yaws, nitrogen, erlyweb. There's some powerful tools, very different paradigm, certainly, from rails, django and PHP.