Listener in Oracle 11g

I am working on a project that uses Oracle 11g, and we were standing up a db for proof of concept in one of the dev environments. I configured listener.ora to point to the instance, but still was having connection problems.

Apparently in your init file, you need the line:

local_listener='MySidName'

To make sure it keeps loading, run the following via sqlplus:

C:\> cd some_path_with_my_init_file
C:\> sqlplus /nolog
SQL> connect / as sysdba
SQL> shutdown immediate
SQL> startup pfile='myinit.ora'
SQL> create spfile from pfile

Hope this helps someone…

Datalayer Decisions (Repository, DAO, Services) in Domain-Driven-Design Applications

I have been working several applications lately at work that use Domain-Driven Design.

I had a couple of questions about design choices I saw made in the applications I’m working with. I recently talked to an architect who uses DDD a lot (Model first), and had the chance to pick his brain. Here’s what I came up with. I’d be curious to hear other opinions via comments:

1. Why choose Repository vs DAO pattern or vice-versa? I even found some Spring posts recommending both.

Answer: Repository fits nicely on a legacy schema. If you’re domain objects do not match the database, then there this pattern works better. For green field, DAO choice means you can simplify mapping, because your schema is under your control.

One additional consideration: DAO model first means that your database may not be normalized and / or friendly for reporting tools etc. If you are in an enterprise setting, that reporting should be done off of a separate schema anyway (data warehouse). The warehouse records can be written in the service layer (see question 2) or extracted via an ETL process batch job. If this is overkill, then you may want to use Repository and map to a friendlier schema.

In the case of using both repository and DAO, this seems to be of value when you are not using an ORM. The DAO simply manages CRUD for one table, and the Repitory layer handles joining and translating entities into domain objects.

2. What is the purpose of a service layer that encapsulates a DAO or Repository?

Answer: There are various concerns that relate to the application, but not the domain model. For example, a Product model will have validation that is true in and of itself. For example, it must have a name, and that name is 50 characters or less. But in the context of an order, there may be additional validation rules that involve various domain models in the context.

So the service layer should provide a single interface for various actions related to domain that the User Interface layer should call. So for instance, a web application has an admin section where I want to delete a product. And a product can only be deleted without orders.

Top to bottom, the stack looks like the following:

  • Web application: Sends request to Product Service to delete a product
  • Product Service:
    • Calls OrderRepository to validate there are no related orders
    • Calls ProductRepository to delete Product

That is rather simple logic in the service, but why should the product repository know about the order repository? These services serve as single endpoints for user interface programmers. They can simply request a product deletion and handle appropriate validation messages / errors. They don’t care about context validation, model validation, and all the sub steps involved, that is handled for them.

And each class follows the single responsibility rule.

Linq to SQL

Background: Linq to Sql is a lightweight data access protocol for the .Net framework.  It supports filtering and other lambda features in code, allowing the programmer to treat their data source as if it were a collection of objects that support flexible features.  In this way, it can be thought of as an ORM mapper, though some might dispute that.  Disclaimer: That is my own oversimplified definition.

I like what I see out of Linq to Sql.  It shows a lot of potential, and the transference of knowledge that should happen when using other forms of Linq (xml, objects) is a nice benefit.  However, there are a lot of questions raised in the community like the following:

http://odetocode.com/Blogs/scott/archive/2008/11/10/12311.aspx

I’ve been in several debates over this.  My concern isn’t that Linq to Sql is bad, but there are serious maintainability issues around code that uses dead Microsoft features.  In the open source world, as long as community members want to use a feature, it will be around.  Trying to get help from a black-listed feature from vendors, consultants, and community members in the Microsoft world isn’t so easy.  You certainly aren’t going to see Microsoft spend time and money adding interop hooks for features that have fallen out of favor.  And how many of your junior programmers five years from now are going to be familiar with a feature from .Net 3.0/3.5 that is shunned in the version du jour. 

Everytime I think about using such a feature, I think of the excited J# developers of the early 2000’s.