Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Pure Object-oriented Domain Model by a DB Guy, Part 1 : Page 4

This is the first in a new series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is more purely object-oriented, while still focusing on roundtrips and the data access code to get good performance.


advertisement

Advantages and disadvantages

I’m sure you can feel my optimism for this new architecture, but without sounding like a salesman or as if I am discussing a cure-all solution, let’s concentrate for a while on the negative aspects. I have already mentioned a few drawbacks with the new architecture, now let’s discuss them and a few more a little more closely.



Less efficient when it comes to RAD (Rapid Application Development)

Visual Studio .NET provides quite a lot of help with adding RAD features if you use the Table Module pattern. If you go for something similar to my new architecture, you will have to create some tools of your own to help deal with some of the repetitive tasks.

Code amount

You will find that in the short run at least, the new architecture will require you to write more code than if you use typed datasets. This goes partly along with the preceding paragraph.

Lack of examples

If you go to MSDN for example, you will find plenty of examples of how to use datasets inside out. The same goes for books too. If you try to find .NET samples for how to write your own object-oriented domain model in .NET, it’s an opposite situation.

Coupling

As I said, it might be a big disadvantage to have so much coupling to the domain model. It’s perhaps better to only expose DTOs to the left of the application layer, but I think that it’s good for some systems without DTOs, and bad for others.

Connected to the coupling problem comes the headache of added versioning problems. If the domain model changes frequently, the consumers are affected too.

You write infrastructure code yourself

You might ask yourself after a while whether you should solve customer problems or write infrastructure code. MS provides you with the infrastructure of datasets and it’s done. If you go for writing a pure domain model, you will have to deal with a lot of complexity. You might end up having a lot of fun, but not solve any customer problems at all.

On the other hand, I think it’s often nice to have full control on your own if the task is manageable, especially for situations when the infrastructure is otherwise changed each and every year. I guess some of you are thinking: How na



Jimmy Nilsson is the owner of the Swedish consultant company JNSK AB (www.jnsk.se). He has been working with system development since late 1988 (with VB since version 1.0) and, in recent years, he has specialized in component-based development, mostly in the Microsoft environment. He has also been developing and presenting courses in database design, object-oriented design, etc. at a Swedish University for six years. Jimmy is the author of ".NET Enterprise Design with Visual Basic .NET and SQL Server 2000" and he often speaks at VSLive conferences.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date